Taxonomy of Scenarios for Automated Driving - Amazon S3 · Taxonomy of Scenarios for Automated...

Taxonomy of Scenarios for

Automated Driving

Technical Report

April 2017

Contents

v1.2

Copyright © Transport Systems Catapult 2017 1

Contents Contents .................................................................................................................................1

Release Conditions ................................................................................................................ 3

Disclaimer ............................................................................................................................. 3

Acronym List ......................................................................................................................... 4

1 Introduction .................................................................................................................... 6

1.1 Overview............................................................................................................................................... 6

1.2 Approach .............................................................................................................................................. 6

1.3 Report Structure .................................................................................................................................. 8

2 Background Research ..................................................................................................... 9

2.1 Relevant TSC Studies .......................................................................................................................... 9

2.2 The Highway Code ............................................................................................................................. 10

2.3 Examples of Automated Driving Taxonomy Exercises .................................................................... 11

2.4 Stakeholder Engagement ................................................................................................................... 12

2.5 Mind the Safety Gap ........................................................................................................................... 12

2.6 Automation vs. Autonomy ................................................................................................................. 18

3 Initial List of Challenging Driving Scenarios ................................................................. 20

4 Goal Structuring Notation ............................................................................................. 23

4.1 Introduction ....................................................................................................................................... 23

4.2 Goal Structuring Notation Concepts and Terminology ................................................................... 23

4.3 Using the GSN to Define a Safe and Working System ..................................................................... 27

4.4 Tolerance of Risk ............................................................................................................................... 29

5 GSN Outputs – ‘Highway Pilot’ Use Case ....................................................................... 32

5.1 Introduction ....................................................................................................................................... 32

5.2 Overview............................................................................................................................................. 32

5.3 Lane Re-allocations (HP1) ................................................................................................................ 35

5.4 Road Etiquette (HP2) ........................................................................................................................ 38

5.5 Lane Rerouting (HP3) ........................................................................................................................ 41

5.6 Adverse Weather (HP4) .................................................................................................................... 43

5.7 Sudden Mechanical Failure (HP5) ................................................................................................... 45

5.8 Intervention (HP6) ............................................................................................................................ 47

5.9 Operational Envelope (HP7) ............................................................................................................. 49

5.10 Obstructions (HP8) ............................................................................................................................ 51

6 GSN Discussion of Outputs – ‘Urban Pilot’ Use Case ..................................................... 54

6.1 Introduction ....................................................................................................................................... 54

Contents

v1.2


6.2 Overview............................................................................................................................................. 54

6.3 Road Etiquette (UP2) .........................................................................................................................57

6.4 Operational Envelope (UP7) ............................................................................................................. 65

6.5 Junctions and Level Crossings (UP9)............................................................................................... 66

6.6 Pedestrian Crossing Arbitration (UP10) .......................................................................................... 69

6.7 Overtaking (UP11) .............................................................................................................................. 77

6.8 Antisocial Behaviour (UP12) ............................................................................................................. 82

7 Summary and Concluding Thoughts ............................................................................. 90

7.1 General ............................................................................................................................................... 90

7.2 Roads and Regulation ....................................................................................................................... 90

7.3 Vehicles and Technology ................................................................................................................... 90

7.4 Standards, Ethics, and Safety Case .................................................................................................... 91

Release Conditions

v1.2


Release Conditions THIS DOCUMENT AND THE INFORMATION IN IT ARE PROVIDED IN CONFIDENCE, FOR THE SOLE PURPOSE OF USE BY THE TRANSPORT SYSTEMS CATAPULT, AND MAY NOT BE DISCLOSED TO ANY THIRD PARTY OR USED FOR ANY OTHER PURPOSE WITHOUT THE EXPRESS WRITTEN PERMISSION OF THE TRANSPORT SYSTEMS CATAPULT, NOT TO BE UNREASONABLY WITHHELD.

Disclaimer This report has been produced by the Transport Systems Catapult under a grant from the Innovate UK. Any views expressed in this report are not necessarily those of the Department for Transport or the Centre of Connected and Autonomous Vehicles.

Acronym List

v1.2


Acronym List

ABS Antilock Braking System

ACARP As Confident As Reasonably Practicable

ACC Adaptive Cruise Control

ADAS Advanced Driver Assistance Systems

A.I. Artificial Intelligence

ALARA As Low As Reasonably Achievable

ALARP As Low As Reasonably Practicable

ALR All Lane Running

AMOR Asset Maintenance and Operational Requirements

ANPR Auto Number Plate (licence plate) Recognition

APS Assisted Parking System

ASIC Application-Specific Integrated Circuit

ASIL Automotive Safety Integrity Level

AV Automated Vehicle

BCR Benefit-cost-ratio

CAA Civil Aviation Authority

CAV Connected and Automated vehicle

CFMEA Concept Failure Modes and Effects Analysis

CIHT Chartered Institution of Highways and Transportation

CMOS Complementary Metal-Oxide Semiconductor

CNN Convolution Neural Networks

DFMEA Design Failure Modes and Effects Analysis

DfT Department for Transport

DMRB Design Manual for Roads and Bridges

DSRC Dedicated Short-Range Communications

DSIWG Data Safety Initiative Working Group

DSP Digital Signal Processors

DVSA Driver and Vehicle Standards Agency

ECAP European Car Assessment Programme

EGNOS European Geostationary Navigation Overlay Service

Ego Vehicle The vehicle under consideration

EPAS Electronic Power Assisted Steering

ERAP European Road Assessment Programme

ERF European Road Federation

ESC Electronic Stability Control

EU European Union

EV Electric Vehicles

FMEA Failure Modes and Effects Analysis (FMEA)

FoV Field of View

FPGA Field-Programmable Gate Array

FRAM Functional Resonance Analysis Method

FTA Fault Tree Analysis

v1.2


GPU Graphical Processing Unit

GSN Goal Structuring Notation

GNSS Global Navigation Satellite System

HAZOP Hazard and operability study

HiL Hardware in the Loop

HMI Human Machine Interface

I2V Infrastructure to Vehicle

LDM Local Dynamic Maps

LDW Lane Departure Warning

LKA Lane Keep Assist

Parc QoS

Total number of vehicles in the country Quality of Service

SFAIRP So Far As Is Reasonably Practicable

SiL Software in the Loop

SoC System on Chips

SOTIF Safety of the Intended Functionality

SRD Systems Requirement Document

STPA Systems-Theoretic Process Analysis

TSR Traffic Sign Recognition

UAS Unmanned Aerial Systems

VMS Variable Message Signs

V2I Vehicle to Infrastructure

V2V Vehicle to Vehicle

Introduction

v1.2


1 Introduction

1.1 Overview

This document has been prepared by the Transport Systems Catapult (TSC) for the Department for

Transport (DfT) and the Centre for Connected and Autonomous Vehicles (CCAV). This report represents

the deliverable of the Project – ‘Taxonomy of Scenarios for Automated Driving’. Any views expressed in

this report are not necessarily those of the DfT or CCAV.

The majority of the driving task is relatively routine, but occasionally situations demand the driver to take

action which is out of the ordinary or requires the driver to make an interpretation of the situation and act

in a considered manner (common sense driving). Such situations could present challenges to Automated

Vehicles (AVs) and their developers. AVs will need to adhere to rules governing their behaviour. If the rules

and regulations governing vehicle behaviour within abnormal situations are not clear, then this could lead

to unexpected or undesirable behaviour amongst AVs. Indeed, AVs may behave differently to the same

abnormal situation depending on the AV manufacturer and the software algorithms that have been

deployed.

Examples of abnormal situations that can be found on the UK highway network might include (but not

limited to) responding to emergency vehicles, navigating temporary traffic management measures,

responding to children that are near to the carriageway, overtaking an unsteady cyclist travelling up hill,

overtaking broken down vehicles, etc. It could include circumstances under which vehicles would need to

mount the footway, or cross solid white lines in order to make progress or make way. For instance, merging

in turn could create a challenge, as could allowing gaps at junctions for other vehicles to pull out. There

are numerous situations that can call upon the driver using ‘common sense’ to allow the traffic to flow

freely or to avoid unnecessary road blockages.

This project investigates abnormal driving situations, and goes on to create a comprehensive ‘taxonomy

of scenarios for automated driving’. It is anticipated that the outputs of this study will start to outline

possible strategies for addressing how to handle some of the more challenging automated driving

scenarios.

1.2 Approach

The term ‘taxonomy’ refers to the branch of science concerned with classification. It is useful to classify

automated driving scenarios so as to create a structured approach to dealing with them, and manage the

complexity of understanding how AVs will cope with real world issues. Therefore, this study has created a

structured approach to classify automated driving scenarios. This includes:

• A structured approach to help resolve the bewildering number of ‘What ifs’?

• A structured approach to grouping the scenarios and issues in a taxonomy exercise.

• A structured approach to forming a model to describe (as an example) how the issues will be

managed.

Ask one hundred drivers to list their challenging driving anecdotes then they may produce a list of one

hundred issues. Ask another group of drivers and there would in all likelihood be a new list, with some

Introduction

v1.2


duplication as well as many new items. By performing a taxonomy on those scenarios, it is possible to

reach an understanding of the broad classes of issues facing AVs in the hope of a common concept

emerging to deal which each class of issue. Using this approach, it should be possible to understand the

likely behaviours and risks emerging from any conceivable eventuality without having codified ‘IF-THEN-

ELSE’ rules to explicitly handle each unique situation that presents itself.

There were two approaches to undertaking this project; the ‘bottom up’ brainstorming approach and the

‘top down’ modelling approach.

The brainstorming approach involved creating a list of issues for the taxonomy using conventional

brainstorming. This forms a bottom up approach by anticipating the sorts of things that could be

challenging based upon everyday driving experiences and reports of more obscure incidents. The

modelling exercise has taken more of a top down approach by considering how the system will

accommodate some of the challenges predicted by the taxonomy exercise. Ideally the two should meet in

the middle, however the groupings of the issues don’t necessarily need to map directly to the coping

strategies, provided there is full coverage, i.e. there is a mechanism which handles each of the issues even

if the strategy is avoidance, by not allowing the vehicle to be exposed to that issue. As an example, a

Highway Pilot type feature would not normally be expected to cope with the arbitration at a rail level

crossing, so there is coverage despite there being no explicit software algorithm designed into the system

for this. How to ensure the feature is only used on the highway and not on more minor roads (which may

have level crossing among many other things) will form part of the model’s argument for that feature, and

may include strategies from just relying on the driver to only use it where it has been designed to work,

for instance through to the use of GNSS/GPS and geo-fencing to actively prevent it being used elsewhere.

The creation of the model’s strategies was undertaken using brainstorming sessions. For this reason, the

strategies will inevitably be non-exhaustive in at least some cases, and are provided as examples as much

as anything else. The modelling technique used is known as Goal Structuring Notation (GSN) and is a

diagrammatic from of argumentation which is explained in more detail in Section 4. It is important to stress

(particularly considering stakeholder review feedback of a previous draft version of this report) that the

use of GSN is not in and of itself a way to ensure full coverage of all potential issues associated with an

automated driving feature. The creation of the GSN may be helpful with that thought process by

structuring the thinking, however it remains just a tool to diagrammatically present the ‘argument’ that

you have full coverage of issues rather than it actually doing the work of finding that coverage.

Beyond the use of just brainstorming, more rigorous techniques might be employed to deal with the

complexities that may not be apparent. It was beyond the scope of this work to investigate those potential

techniques since it began as an exercise to explore issues faced in everyday conventional driving in the

context of AVs. However, two techniques for modelling and understanding accident causality, have been

highlighted by a stakeholder since the first draft release of this report. The first is Systems-Theoretic

Process Analysis (STPA)1, a hazard analysis technique used to identify scenarios leading to identified

1 STPA Primer (paper) and Engineering a Safer World (book) http://psas.scripts.mit.edu/home/home/stpa-primer/

http://psas.scripts.mit.edu/home/home/stpa-primer/

Introduction

v1.2


hazards so they can be eliminated or controlled. STPA generates a larger set of failure causes compared to

traditional techniques. These causes may not involve component failures or unreliability. STPA was

designed to also address increasingly common component interaction accidents, which can result from

design flaws or unsafe interactions among non-failing (operational) components. The second, known as

the Functional Resonance Analysis Method (FRAM)2, is another technique which helps to model the

interactions or resonance which can occur between normally benign actions and events which can

sometimes lead to unexpected and disproportionate outcomes. Put simply, it does so by dividing the

system up into functions then considers the potential variabilities on the interactions between those

functions.

A final consideration of the approach taken in this work is that it largely considers the issues in isolation.

This may be a hang-up from current automotive thinking of requiring robustness to single-point-failures

which assumes that failures are rare therefore can be treated as occurring discretely in time upon which a

safe condition can be entered (usually power down, deactivate or inhibit then rely on the driver to manage

the situation). However, when dealing with issues of the real-world environment rather than component

failures, we may find that multiple issues occur at any one time. It may be valid to assume that rare unusual

events will not occur at the same time (to any realistic probability), such as an animal being loose on the

highway will not occur in the same instant that a sink hole appears in front of a collapsing bridge while at

the same time the pilot of a light aircraft is looking for a good place to perform an emergency landing.

However, there is no reason to assume that any of these will not occur during poor weather conditions

while people are also fleeing their abandoned vehicles on-foot on the highway due to the same event.

Multiplicative complexity is a real issue that remains whilst dealing with issues one-at-a-time is still

challenging enough.

1.3 Report Structure

This report is structured as follows:

• Section 2 summarises background information that was researched as part of the study, including a

summary of relevant TSC studies and external reports, the Highway Code, and automotive safety

related information which is of relevance to the challenges associated with AVs.

• Section 3 includes an initial long list of challenging driving situations for AVs.

• Section 4 introduces GSN, which is the tool used to structure the issues associated with challenging

AV driving scenarios, and outlines some considerations with its use.

• Section 5 presents the GSN outputs associated with the Highway Autopilot use case.

• Section 6 presents the GSN outputs associated with the Urban Pilot use case.

• Section 7 provides concluding comments.

2 FRAM Handbook http://functionalresonance.com/how-to-build-a-fram-model/fram-handbook.html

http://functionalresonance.com/how-to-build-a-fram-model/fram-handbook.html

Background Research

v1.2


2 Background Research

This section summarises some of the background research that was undertaken as part of this project.

2.1 Relevant TSC Studies

This document sits alongside other reports undertaken by TSC on behalf of DfT / CCAV. The following

studies were completed within the 2015 / 16 financial year:

Project Name Study investigates / provides:

Data recording guidelines for AVs • Reasons for data logging

• Importance of logging different types of

data

• Guidelines for AV data logging

Functional Safety (with respect to AV

regulation)

• Current process for automotive safety

• How safety cases could be developed for

AVs

• Considerations for regulators.

Pods on pavements • Collated information with respect to

automated vehicles operating in

pedestrian environments

AV map data requirements • Requirements of map data for AV systems

Planning and preparing for CAVs • Stakeholder / literature recommendations

on what public sector can do to accelerate

CAV agenda.

Exploring the relationship between CAVs

and energy usage and emissions

• Systems dynamics modelling tool and

learnings for examining relationships

Investigating the case for safety database

for AVs

• Database benefits and risks

• Potential database features

• Implementation options

Table 1: Relevant TSC Projects undertaken 2015 / 16 Financial Year

The following projects are scheduled to be completed by the end of the 2016 / 17 financial year:

Background Research

v1.2


Project Name Study investigates / provides:

Safety Aspects of AVs • How safe high level automation features

need to be

• Approaches to safety cases from

technology developers

• Societal attitudes towards risk from CAV

technology

Retrofitting connected vehicle technology • Minimum level of vehicle retrofit needed

to facilitate selected connectivity

applications

Standards for CAVs • Builds on previous TSC work to map

existing relevant standards in CAV

domains.

Future Proofing Infrastructure for CAVs • Opportunities for updating policy and

guidance documents with respect to CAVs

to help future proof UK infrastructure

Landscape review of CAV research • Current work being undertaken by UK

research organisations which could be

relevant to CAVs

Table 2: Ongoing TSC Projects, 2016 / 17 Financial Year

The latest versions of the deliverables of each project have been sent to the project sponsors for each

project. Interested parties can request further information from TSC.

Of particular relevance is ‘Functional Safety (with respect to AV regulation)’ and ‘Safety aspects of AVs’

projects, both of which consider the safety of AVs. The findings of this report will feed into ‘Safety aspects

of AVs’, and vice versa.

2.2 The Highway Code

In order to start compiling a list of numerous real-world issues faced in everyday driving, the Highway Code

was consulted, which represents the rules of the road for road users. Within the introduction to the

Highway Code it is stated:

“Many of the rules in the Code are legal requirements, and if you disobey these rules you are committing a criminal offence. You may be fined, given penalty points on your licence or be disqualified from driving. In the most serious cases you may be sent to prison. Such rules are identified by the use of the words ‘MUST/MUST NOT’. In addition, the rule includes an abbreviated reference to the legislation which creates the offence. Although failure to comply with the other rules of the Code will not, in itself, cause a person to be prosecuted, The Highway Code may be used in evidence in any court proceedings under the Traffic Acts (see The road user and the law) to establish liability. This includes rules which use advisory wording such as ‘should/should not’ or ‘do/do not’.”

https://www.gov.uk/guidance/the-highway-code/annex-4-the-road-user-and-the-law#roaduserlaw

Background Research

v1.2


The Highway Code has been written, naturally, for human drivers, and assumes an associated level of visual

perception and intelligence. For example, ‘Rule 144’ states you MUST NOT:

• Drive dangerously

• Drive without due care and attention

• Drive without reasonable consideration for other road users.”

It may be difficult to define to an AV control system what ‘reasonable consideration’ for other road users

is. Studying Rule 144 in conjunction with the paragraph above, leads one to surmise that failing to act with

reasonable consideration for other road users represents a legal requirement.

Another example where an associated level of perception and intelligence is required can be found within

Rule 200, which states:

“Choose an appropriate place to manoeuvre. If you need to turn your vehicle around, wait until you

find a safe place. Try not to reverse or turn round in a busy road; find a quiet side road or drive

round a block of side streets.”

An AV may struggle to determine the points within this rule, such as how to decide what is a safe place

and what constitutes a busy or quiet road. It is also unclear what the vehicle should do if it must turn

around but cannot get to a ‘quiet’ road to do so.

Rule 200 presents a different type of challenge for AVs:

“Older drivers. Their reactions may be slower than other drivers. Make allowance for this”

To determine even the approximate age of other road users represents a considerable challenge for AVs.

Even if it was possible to do so, it is then unclear how the AV expected to ‘make allowance’ for them.

2.3 Examples of Automated Driving Taxonomy Exercises

A relevant report, titled ‘Use Cases for Autonomous Driving’ was published by Walther Wachenfeld and

Hermann Winner in 2014.3 The report outlines a set of characteristics to describe automated driving use

cases. These include:

• Type of occupant;

• Maximum permitted gross weight;

• Maximum deployment velocity;

• Scenery (type of road on which vehicle can operate);

• Dynamic elements (extent to which vehicle can mix with other road users, i.e. level of segregation);

3 https://www.daimler-benz-stiftung.de/cms/images/dbs-bilder/foerderprojekte/villa-ladenburg/Villa_Ladenburg_Use_Cases_English_Release_2.pdf

https://www.daimler-benz-stiftung.de/cms/images/dbs-bilder/foerderprojekte/villa-ladenburg/Villa_Ladenburg_Use_Cases_English_Release_2.pdf

https://www.daimler-benz-stiftung.de/cms/images/dbs-bilder/foerderprojekte/villa-ladenburg/Villa_Ladenburg_Use_Cases_English_Release_2.pdf

Background Research

v1.2


• Information flow between driving robot and other entities (for example, vehicle may receive path

planning information or even direct control commands from outside sources);

• Availability concept (the extent to which the driver, or other entities, can take control of the vehicle

within the operational envelope);

• Extension concept (who, if anyone, can take control of the vehicle at the boundary of the operational

envelope);

• Options for intervention (on what basis can the occupant, or other entities, intervene in the driving

task).

This study is useful in defining types of AVs, and their capabilities. In addition, the Adaptive Deliverable

2.14, which presents a systematic approach for the classification of automated driving and parking

functionalities, was reviewed.

2.4 Stakeholder Engagement

The project and its approach was discussed with a number of key stakeholders. The themes discussed fed

into the formulation of potential strategies for handling driving scenarios, discussed later in this report,

but it revealed the variety of approaches being taken to the issues associated with automated driving.

2.5 Mind the Safety Gap

This section outlines general research and discussion into safety issues related to the automotive industry

and AVs. The following is considered as important ‘food for thought’ prior to discussion of the taxonomy

itself, and builds on information provided or being developed as part of previous and ongoing TSC studies,

as outlined in Table 1 and Table 2.

2.5.1 Current Industry Practice

ISO 26262 is the automotive industry self-adopted IEC 61508 derivative functional safety standard which

has the goal of avoiding potentially safety critical situations caused by hardware and software failures and

is generally applied to systems under software control. A limitation of this standard which is not always

recognised is that it only covers fault failures and not the so-called Safety of the Intended Functionality

(SOTIF). Therefore, the functional insufficiencies of ADAS features are not covered and manufacturers are

left to satisfy themselves that the systems are robust and reliable enough to sell in terms of the potential

for litigation and damage to their reputation.

Weaknesses in estimation, interpretation and prediction steps can have consequences comparable to

those of hardware and software failures, yet the means to formally ensure that equivalent safety to fault

4 https://www.adaptive-ip.eu/index.php/deliverables_papers.html?file=files/adaptive/content/downloads/Deliverables%20%26%20papers/AdaptIVe-SP2-v12-DL-D2.1%20System%20Classification.pdf

https://www.adaptive-ip.eu/index.php/deliverables_papers.html?file=files/adaptive/content/downloads/Deliverables%20%26%20papers/AdaptIVe-SP2-v12-DL-D2.1%20System%20Classification.pdf



Background Research

v1.2


failures is met has not yet been put in place or even a consensus reached as to how it should be

undertaken. An attempt to address this issue for ADAS (SAE Level 0-2) has been made, currently in draft

at the time of writing5.

The main vehicle motion controls are formed of the familiar accelerator, brake and steering mechanisms.

When these are brought completely under software control there are new risks associated with each of

them. The principal is the same for all three, but it is perhaps easiest to visualise the potential hazards in

the case of commanded steering, since a relatively small error in steering angle can result in a catastrophic

head-on collision between vehicles.

Existing Electronic Power Assisted Steering systems (EPAS) have been developed to meet ISO 26262

Automotive Safety Integrity Level (ASIL) – D. ASIL is established by performing a risk analysis of a potential

hazard by looking at the Severity, Exposure and Controllability of the vehicle operating scenario. Four

levels, A to D, are used to represent ASIL with D representing the most stringent and A the least stringent

level. ASIL D represents likely potential for severely life-threatening or fatal injury in the event of a

malfunction and requires the highest level of assurance that the dependent safety goals are sufficient and

have been achieved. This concerns both the process under which EPAS are developed as well as the design

implementation. The ASIL-D rating comes because of the hazard arising from unintended or unintentional

steering, being of the worst combination of exposure, lack of controllability by the driver, and severity of

the consequences. When considering fully automated vehicle control (which is not within scope for ISO

26262) it is not clear what to do with the controllability rating C, except to set it to the case worst level C3

(90% or more of drivers would not be able to maintain enough control to avoid the hazard). The hazard of

steering into the path of an oncoming vehicle cannot be understated as the closing speeds can be over

double the speed limit (if both vehicles are slightly exceeding it) and the results of a collision are often

catastrophic. If the steering command is passed from another software function hosted on another

module, then the same hazard severity remains with the same potential consequences.

2.5.2 Fault Tolerant Fail Active Actuator Design Is Now Needed

From a component perspective, the existing design of EPAS has been done with the mechanical fall back

left in place (the steering wheel is physically connected to the road wheels) so that it can be inherently

failsafe just by deactivating the steering assistance. The very recent emergence of steer-by-wire into the

market place still leaves a mechanical fall back using a clutch to reconnect the mechanical link to the

wheels. If a fault is detected, then the system can power down and leave the driver with heavy but

controllable steering. If a mechanical fault occurs such as a snapped drive belt between the drive motor

and the steering rack, the driver is still able to steer the vehicle unassisted. If the driver is no longer

expected to be in a position to immediately take back control at all times due to automation of the driving

task, then it is likely that some redesign and re-evaluation of the fault failure cases will be needed. Because

of the lack of human involvement, it may no longer be acceptable for power steering loss to occur from a

single drive belt breakage or for a systematic fault to cause the steering system to just power down and

go in to a fault mode. The same may also be true for the brake system which has a mechanical-hydraulic

fall back, assisted or unassisted foundation braking is always available to the driver, so redundancy of the

5 ISO/AWI PAS 21448 Road vehicles -- Safety of the intended functionality.

Background Research

v1.2


electrical systems for fail-active fault-tolerance behaviour has not thus far been needed for any of the

primary controls.

2.5.3 Has Constrained Operation Slid into Full Authority?

Fault tolerance and fail-active behaviours are of limited concern when compared to the issue that

commanded steering has the potential to cause. Pre-existing systems such as park assist can be offered

without this being an issue, as their speed of operation is limited by the EPAS controller, this is known as

ASIL decomposition. The high integrity module (EPAS) constrains the steering commands from the low

integrity module and so ensuring safety. If the vehicle’s speed exceeds a certain threshold, then the EPAS

controller stops accepting external steering commands from the parking module. The available steering

torque for commanded steering is also limited in the order of 3Nm, such that the driver can manually

overpower and intervene if required. This functionality can be protected to ASIL-D as part of the EPAS

controller’s design and is generally covered by Type Approval for many regions in the world. Having this

architecture allows system designers to implement automatic parking functions from a hardware module

other than the EPAS controller which may have no ASIL rating, or usually ASIL-QM (quality management)

and can be running arbitrary software acting on information provided from low integrity ultrasonic parking

sensors. The driver is responsible for monitoring the environment around the vehicle and in the event of

a failure.

Crucially, if we now remove the driver from the parking manoeuvre and require the EPAS controller to

accept steering command potentially at any speed and full steering torque, then this changes everything

as the ASIL-D protected constraints have been removed; the software issuing the steering commands has

become responsible for preventing an incorrect steering decision whilst the EPAS controller is now

responsible for executing it in the way requested. The change in steering authority means that the module

issuing the steering commands has now also inherited the ASIL-D hazards whilst the EPAS controller has

new additional responsibilities to guarantee that the steering commands are executed.

2.5.4 Tech Demonstrations are not Proof of a Safety Concept

What is currently being demonstrated, and even promised for production, is to produce steering

commands from high performance, but general purpose, computing hardware which sits at the opposite

end of the spectrum to the type of hardware currently used for ASIL-D applications, namely low

performance highly reliable/resilient lockstep microcontrollers rated to AEC Q100 for suitability for

operation in harsh automotive environments. A recent trend has seen the move towards high performance

parallel computing. This can take the form of Graphical Processing Units (GPUs), Digital Signal Processors

(DSPs), programmable logic Field-Programmable Gate Array (FPGAs) and other hardware variants such as

custom silicon Application-Specific Integrated Circuits (ASICs). High processing performance is needed to

resolve the complexity found in the real world, whether for image processing and object recognition, or

using Artificial Intelligence (AI) techniques such as Convolution Neural Networks (CNNs) used for both

image processing object classification, situation recognition and for decision logic. These processing units

are normally incorporated with additional conventional CPU cores onto what are known as System on

Chips (SoCs) such as those used in consumer electronics e.g. smart phones and tablets, and often lack the

non-obligatory AEC Q100 rating. This heterogeneous silicon design does not lend itself well to current

safety practises, both from a software and a hardware perspective, and fault failures may again become

an issue. However, the real difficulty is that high performance processing may be required from the

Background Research

v1.2


perspective of resolving the complexity of the real world which leads us into the paradox of what it means

to be safe, as discussed below.

2.5.5 The Design Complexity Paradox

There is an ongoing debate as to how many miles should be driven before AVs are ‘proven’ to be safe.

Existing EPAS controllers may have been ‘proven-in-use’ as is said in the industry. However, they have been

developed via a process to be safe-by-design rather than relying upon accumulated mileage to

demonstrate that they are safe. It is possible to have several billion miles driven without issue as a fleet

total, then in the next mile an area of memory or processor register is corrupted by events beyond the

developers and designers immediate control that has not been corrupted before which then results in a

catastrophic failure if this has not been explicitly accounted for by a failsafe design. This is a fault failure

which is difficult to prevent, but the effect of such a failure can be guarded against at the design stage by

accepting that random failures can occur at any time. This example just considers fault failures which are

covered by ISO 26262. The systems currently being demonstrated for highly automated vehicles do not

currently meet with this fault failure approach from both the perspective of the general-purpose hardware

it is running on and the architecture of the software itself. It is conceivable that the hardware could be

developed to meet the safety integrity requirements with significant time and effort, but is it less clear

how this can be achieved for the software at its necessary complexity is entirely at odds with the normal

processes for development of safety critical software. A relevant article was published by Dr Steven

Shladover in the June 2016 edition of Scientific American:

“Software for automated driving must therefore be designed and developed to dramatically

different standards from anything currently found in consumer devices. Achieving these standards

will be profoundly difficult and require basic breakthroughs in software engineering and signal

processing. Engineers need new methods for designing software that can be proved correct and

safe even in complex and rapidly changing conditions. Formal methods for analyzing every possible

failure mode for a piece of code before it is written exist—think of them as mathematical proofs

for computer programs—but only for very simple applications. Scientists are only beginning to

think about how to scale up these kinds of tests to validate the incredibly complex code required to

control a fully automated vehicle. Once that code has been written, software engineers will need

new methods for debugging and verifying it. Existing methods are too cumbersome and costly for

the job.”

This is particularly true for CNN approaches where the input/output relationship is obfuscated by its nature

of modelling complex processes and many of the normal techniques that provide checks and measures

such as limiting design complexity and code reviews do not readily apply as the link between the code and

the functionality is not clear. This leads us into the notion of functional insufficiencies.

2.5.6 Functional Insufficiencies

While sales volumes of CAVs remain a low proportion of the total vehicle parc, the limitations of algorithms

are more likely to manifest in real-world incidents than hardware fault failures since these can take many

cumulative years of fleet operation to manifest. Current ADAS features rely heavily on the driver to take

over control in the event of an anomaly, so can err on the side of caution against positive actuation. They

Background Research

v1.2


can favour inaction over action and allow the driver to override in either case. Even stability control

systems are there to assist the driver, not to guarantee stability under all conditions. The approach can

often be leaning towards providing sufficient actuation to pass the tests (such as Euro NCAP), but be

conservative in the real world to minimise false activations.

However, with the driver removed from the loop, both false positive (action when not required) and false

negative (inaction when action is required) can be equally hazardous with potentially much higher

consequences without a driver to handle the situation.

Sensing and perception limitations often mean that the trade-off between preventing false negatives and

false positives is complex and difficult, as to improve the performance of one results in a significant

worsening of the other, with the middle ground providing unacceptable performance of both. This

detection trade-off is known as the receiver operating characteristic of a sensor or system.

2.5.7 Receiver Operating Characteristic Trade-offs

Often there may be no suitable compromise which prevents both false negatives and false positives with

a system that performs some form of detection function, which for a CAV could be something such as

detecting a pedestrian crossing the road. This problem is highlighted with Tesla’s version 8 software

update. The system on board the Tesla vehicle could not rely solely on either the radar or camera sensors,

as there are times when both do not work effectively. Radar is not generally used stand alone for stationary

objects, since there would be constant false activations instigated by environmental features such as

passing gates, manhole covers, and low bridges. The camera cannot cope with all light conditions and

atmospheric conditions such as fog, mist, heavy rain etc. The Tesla strategy to resolve the functional gap

is to use a crowd sourced map of false-positive radar detection locations which can then be used to inhibit

unwanted brake activations that would be based solely upon radar derived sensing. There is nothing to

stop a legitimate hazard coinciding with an identified false positive location, although this is statistically

less likely to occur and will inevitably improve confidence in the system without the underlying problem

having been resolved. However, the driver is still expected to take ultimate responsibility for the vehicle

and be ever vigilant, so this is an example of a fall-back measure which reduces the statistical likelihood of

an inattentive driver crashing into a collision risk with the Autopilot feature active. For the current Tesla

fleet size this may reduce the actual crash occurrence rate to zero, but does not actually remove the

problem, only masking it whilst placing a new reliance upon external data for the safe operation of the

vehicle.

Background Research

v1.2


2.5.8 Approaches to Testing

At the current time the only tool in the box seems to be on-road testing (and possibly simulation) to see

what happens. The difficulty with an approach of endurance testing is that safety cannot be proven just

by the absence of failures. The automotive industry has often used a proven-in-use argument (particularly

prior to the adoption of ISO 26262) to cover the quality and safety of component design uncertainties and

component reuse. This is only really a confidence measure which helps to assure component safety but

does not always ensure it. Since road crashes and deaths are rare events when considered for individual

vehicles, miles without crashes are a poor surrogate marker for the ultimate competency of safety of the

software system. Some events happen at such infrequent intervals (examples could include bridge

collapses, animals in the road) that are independent of distance travelled and exposure to these events

cannot be accelerated just by accumulating more mileage on the road. Testing for determinism with

system reaction and behaviour to these events can only be achieved by inducing them under controlled

conditions rather than waiting for them to happen to a test vehicle. Another approach is to accept the

system limitation and instead try to limit or prevent the real-world occurrences so that the system will not

likely ever have to encounter them, thus circumventing the need to test.

Finally, by always assuming that the system can and will fail under certain conditions, the performance

during failure can be assessed by inducing the failure rather than waiting for them to happen. For example,

if a Vehicle to Infrastructure (V2I) strategy is assumed for signalling at junctions, then the performance

during a signal outage or corrupted message can be demonstrated by design and then tested to make sure

that the vehicle still cannot run a red light, rather than testing to show that the communication system is

robust and therefore can be relied upon (until the day it cannot be).

2.5.9 A Safer Nested Architecture?

Is there an architecture which can use simpler legacy control methods to constrain the functionality and

ensure a basic minimum level of safety and predictability without preventing the expected action to be

taken during unusual and challenging situations? It is hard to conceive how this could work without

providing a means for the complex (lower integrity) system to override the simpler (high-integrity) one,

which provides a weak link that defeats the original objective of providing high-integrity constraints. If this

could somehow be achieved, then it may allow more complex systems to be supervised and ‘plausibility’

or ‘sanity checked’ by a simpler safety rated software system. Could it allow far more nuanced adaptive

behaviours to be applied, provided they can live within enforced behavioural limits? Or will there always

be complex scenarios which will require full control authority to resolve and mitigate hazards?

The benefit of the approach of this taxonomy exercise is that it may help to move from a performance

based testing process to one of compliance. The method of identifying classes of issues, deciding upon

a strategy to handle or mitigate them, and looking for compliance/conformance with that strategy,

leaves far less to chance over a performance based approach. With a performance approach where

miles are driven to increase the chances of encountering an unusual event which may or may not push

the system beyond its limits, the absence of which is then offered as proof that the system is safe for

deployment.

Background Research

v1.2


A similar idea is presented in a paper6 presented at the 2016 SAE World Congress, which raises many

testing and validation concerns for AVs along with the implied recommendation for a phased deployment.

A monitor/actuator approach is described as well as a failover mission strategy, using a separate high

integrity failover autonomy system capable of bringing the vehicle to a safe state using minimal

redundancy. In this case the failover system might be a simpler redundant system capable only of bringing

the vehicle to a safe rest position (the ‘mission’) when a problem or abnormality is detected in the main

control system.

Other designs might be based around so-called Byzantine fault tolerance, where redundant controllers are

used to vote to agree on the correct control action. To help prevent common mode failures (all controllers

make the same mistake for the same reasons), the controllers should be of diverse design, unlike typical

modern aircraft systems which expect identical outputs from homogenously redundant systems. Where

two controllers are used and the outputs do not sufficiently agree, then a failover mission capability would

be required to bring the vehicle to a safe condition. If three are used in a majority voting system, then at

least two of them would have to agree, else the failover mission capability would again be needed. Even if

this approach is found to work, then it remains a difficult challenge to ensure genuine independence

between the systems, without creating an unusable system, where they are always bickering, failing to

sufficiently agree, so that the vehicle is constantly being brought to a halt as part of its failover mission.

2.6 Automation vs. Autonomy

The terms autonomous vehicle and automated vehicle are being used interchangeably as synonyms of

each other, and there is debate over definition of what full autonomy actuals means. Some dictionary

definitions are as follows:

1. “One who gives oneself one’s own law”

2. “Freedom from external control or influence; independence”

3. “The right or condition of self-government”

4. “(philosophy) The capacity to make an informed, uncoerced decision.”

5. “(mechanics) The capacity of a system to make a decision about its actions without the involvement

of another system or operator.”

A comparison with the aviation industry and autonomous cars is made by a report7 on the challenges facing

an autonomous car’s risk assessment; SCSC Developing Safe Systems’ where the UK Civil Aviation Authority

(CAA) are described as using the second dictionary definition above to define autonomy for Unmanned

Aerial Systems (UAS) and states that no UAS currently meet the definition of autonomous, instead they

are highly automated or high authority automated systems. The CAA requires that all UAS perform

6 Challenges in Autonomous Vehicle Testing and Validation, Koopman et al, SAE 2016-01-0128 https://users.ece.cmu.edu/~koopman/pubs/koopman16_sae_autonomous_validation.pdf 7The challenges facing an autonomous car's risk assessment, Developing Safe Systems Proceedings of the Twenty-fourth Safety-Critical Systems Symposium, Brighton, UK http://scsc.org.uk/paper_131/18%20Spencer%20-%20The%20challenges%20facing%20an%20autonomous%20cars%20risk%20asessment.pdf?pap=999

https://users.ece.cmu.edu/~koopman/pubs/koopman16_sae_autonomous_validation.pdf

http://scsc.org.uk/paper_131/18%20Spencer%20-%20The%20challenges%20facing%20an%20autonomous%20cars%20risk%20asessment.pdf?pap=999

http://scsc.org.uk/paper_131/18%20Spencer%20-%20The%20challenges%20facing%20an%20autonomous%20cars%20risk%20asessment.pdf?pap=999

Background Research

v1.2


deterministically with their response to any set of inputs being the result of pre-designed data evaluation

output activation processes.

There has also been much recent discussion as to the miss-naming of features using the term pilot such as

Tesla’s Autopilot, Audi’s Piloted Driving, and Volvo’s Pilot Assist, with suggestions that these names are

misleading. The term Autopilot is associated with aviation and marine sectors from which it does not refer

to any single set of functionality, but rather refers to what is in effect an ‘auto-mation’ pilot used to reduce

the workload of trained operatives and not an ‘auto-nomous’ pilot. Aside from the possible pubic

misconception, the real limitation is that what is required and expected for so-called driverless cars is full

autonomy. A problem arises due to the fact that the superposition of many automation features produces

something which appears to approximate autonomy but in fact falls dangerously short of it, as the system

is merely responding to inputs and lacks the contextual awareness that is expected of a human driver to

overcome the challenges of everyday driving. Many unusual scenarios may appear complex or difficult to

detect for automation software, but if presented to a human driver may result in a simple and obvious

mitigation such as just slowing or stopping the vehicle. The word automation can suggest repetitive factory

production line actuation, which has no feedback control, and requires constant monitoring and

supervision. However, what is currently being demonstrated by the automotive and technology industries

is a form of sophisticated automation and with that comes limitations and risks arising from unexpected

scenarios. As with any automation system, these residual risks need to be scoped and planned for at the

design stage so that they can be mitigated for (i.e. using ALARP principles). If society is prepared to take

on these new risks, and be persuaded by the benefits of automation, then the risks should be evaluated

and stated plainly, and perhaps put to some form of public consultation. The danger otherwise is that

before the risks are realised, they are gradually introduced through increasing levels of vehicle automation

being miss-labelled as autonomy and potentially played down by the vehicle manufacturers as they

compete amongst each other for market share by offering the latest boundary/precedence stretching

feature. Once the accepted risk tolerance level is understood or decided, then this can be used as a basis

for setting target maximum acceptable occurrence rates of undesirable scenarios against which systems

and procedures can be developed, tested against then monitored with the aim of continuous

improvements.

Initial List of Challenging Driving Scenarios

v1.2


3 Initial List of Challenging Driving Scenarios

In order to start to classify potentially challenging driving scenarios, it was first necessary to list them. A

brainstorming exercise held amongst TSC staff produced a list, and they were then grouped into categories.

The resulting list (see Table 3) is not exhaustive, but provides an indication of the type of events considered

and the categories into which they were initially placed:

Category Abnormal / Challenging Driving

Event

Issues involved

Obstructions

Parked vehicles

How to ensure they are parked and have not

momentarily stopped. How to allow for possibility of

doors opening?

Disabled (broken down / crashed)

vehicles

Passing may lead to compromising other rules of road

such as crossing solid white lines

Pedestrians

How much space to leave? Different clearances for

different types? Pedestrian behaviour can be

unpredictable. Should vehicle slow down when

passing pedestrians on footway?

Passing cyclists

How much space to leave? Different clearances for

different types? Cyclist behaviour can be

unpredictable.

Road flooding Difficult to sense the depth? Could lead to loss of

control of vehicle or splashing of pedestrians.

Animals in road (either

shepherded or loose)

For smaller animals, it can be difficult to decide

whether to pass over animal or attempt to stop or

swerve.

Ridden horses Determining appropriate speed and overtaking

strategy.

Negative obstructions such as pot

holes or road / bridge collapse Could be difficult to sense.

Load shedding from other

vehicles

Action could depend on density / mass of objects being

shed, but might not be possible for machine to

determine.

Vehicles in process of becoming

disabled, e.g. tyre blow out, lorry

jack knifing, tall vehicle

overturning in wind etc.

Challenging for machine to detect and interpret subtle

clues that provide indications.

Traffic calming measures Speed humps, chicanes, etc. need to be detected and

negotiated appropriately.


v1.2


Fallen power cables / branches in

carriageway Could be challenging to detect with sensors.

Level crossing Similar to traffic signal but consequences of stopping

on rail line could be catastrophic.

Overtaking Challenging to detect oncoming vehicles

Lane reallocation

/ rerouting

Temporary lane closure on

highway

Road layout may differ from map being referred to by

vehicle

Temporary contraflow Automated driving feature may be designed for

highways and not for two-way traffic operation

Lane designations (e.g. bus lanes,

high occupancy vehicle lane, hard

shoulders)

May need to clarify under what circumstances vehicles

can enter.

Adverse weather

/ environmental

conditions

High winds Loss of control

Snow either falling or on

carriageway

Sensor visibility compromised, road markings and kerb

lines obscured, loss of vehicle control

Heavy rain Sensor visibility compromised, road markings

obscured, loss of vehicle control

Ice Loss of control

Fog / bright sunshine etc. Sensor visibility compromised

Road Etiquette

Emergency vehicle in vicinity How to avoid impeding whilst obeying rules of road

Crossing white lines Under what circumstances can vehicle do this?

Interpreting gestures from other

road users

Challenging to detect and interpret the meaning of

hand gestures, flashing of headlights, etc.

Traffic flow

arbitration

Police or authorised persons

intend to stop AV

How does AV recognise what is an authorised person,

and then interpret commands?

Two lanes merge into one Often involves interaction between human drivers

Merging onto highway Often involves interaction between human drivers

T junction Poor lateral field of view from AV

Cross-roads Poor lateral field of view, right turn stale-mate

Temporary speed limits How to ensure location is communicated to AVs

Temporary traffic signals How to ensure location is communicated to AVs

Temporary stop-go sign Can AV interpret?

Giving way to oncoming vehicles

on narrow section of road

Often required communication between human drivers

to decide who proceeds first

Roundabouts Detecting correct lane allocations, ‘give way to right’

standoff


v1.2


Zebra crossings Giving way to waiting pedestrians

Traffic signal failure Junction reverts to priority based, or interaction

between human drivers

Table 3: Initial long list of challenging driving scenarios for AVs

Goal Structuring Notation

v1.2


4 Goal Structuring Notation

4.1 Introduction

This section introduces concepts and terminology associated with the Goal Structuring Notation process.

The resulting diagrams are presented in full in Sections 5 and 6, but it is important to first

understand the methodology, as described here.

This section also includes a discussion as to how the GSN can be used to define a safe and working system,

and tolerance of risk which will need to be considered with the move to automation.

Discussion of the outcomes of the GSN is included within Section 5 and Section 6.

4.2 Goal Structuring Notation Concepts and Terminology

Goal Structuring Notation8, or GSN, is a goal model technique that is can be used to make safety cases to

satisfy the regulator in safety-related industries, but can also be applied just as well to a more generalised

structured argumentation. In simple terms, one generally starts with a high-level goal such as “My system

is safe” given the context of “here’s how and where it will be used” and “here’s why it’s safe…”. The idea

is to form a structured argument around something, usually why a system will be safe in operation, hence

GSN is a structured form of argumentation. Since it is an argument it is subjective and the reader is invited

to scrutinise it so as to become convinced as to its validity and therefore that the top-level goal or assertion

is true, such as the system described will in fact be safe in use.

The GSN Community Standard defines GSN as the following:

GSN is a graphical argumentation notation that can be used to document explicitly the individual

elements of any argument (claims, evidence and contextual information) and, perhaps more

significantly, the relationships that exist between these elements (i.e. how claims are supported by

other claims, and ultimately by evidence, and the context that is defined for the argument).

Arguments documented using GSN can help provide assurance of critical properties of systems,

services and organisations (such as safety or security properties).

An advantage of GSN is it helps make complex issues and relationships clear and understandable, without

the need for large quantities of descriptive text.

The automotive industry is currently a largely self-regulated industry which collaborates in some ways and

competes in others. As it lacks a regulator there is often no safety case written for external review, but the

individual companies satisfy themselves of quality and safety through internal standards and adherence

to some notion of industry best practise. Techniques such as Failure Modes and Effects Analysis (FMEA)

and more recently design (DFMEA) and concept (CFMEA) FMEAs and variants of them are used as

documentary evidence that due thought and process has been applied to potentially injury causing

8GSN Community Standard Version 1: http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf

http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf


v1.2


failures, and wider quality issues which can lead to financial and reputational losses for the company.

FMEAs are conceptually similar in some ways to GSN, but lack the overall narrative for the whole system.

They highlight areas of potential weakness, attempt to quantify the seriousness of those weaknesses and

describe the mitigating step or actions put in place to address the weaknesses.

For the purposes of this work, GSN has been used to construct a general argument towards the safe and

practical deployment of a limited set of automation features (highway and urban automation) for road

vehicles in the United Kingdom (UK), although the issues addressed will inevitably be applicable more

widely than just the UK. Where appropriate it references when an FMEA would form a basis of support for

the argument to show that all plausibly lower level failures have been considered. It is not intended to be

a detailed and complete safety case for AVs, however it does try to lead the reader towards the recognition

of the practical (and sometimes inconvenient) issues faced on the way to formulating a full safety

argument.

It is felt that at the time of writing the industry is tackling the challenges faced in placing an AV onto UK

roads in a siloed manner, i.e. by considering the vehicle as an individual entity rather than the vehicle as

part of a complete system including infrastructure, other vehicles and the users. As is the case in other

industries, each new deployment is considered a new case (change of context) which may invalidate

previous assumptions and therefore some re-evaluation is usually required.

The following sections describe some of the terminology peculiar to the GSN techniques. This includes:

• Goals

• Contexts

• Justifications

• Assumptions

• Strategies

• Solutions

• Modules

4.2.1 Goals

A goal is a basic assertion of something which is deemed or required to be true. It maybe that the system

is required to perform in a certain way or to a certain performance level to uphold that goal, so goals are

supported by further goals until there is nothing further to add except the evidence that the goals will be

met.

Figure 1 : Example of a GSN goal

4.2.2 Contexts

Context provides the landscape or clarification for a goal or strategy. The highest-level goal should always

be provided with some context, as a goal cannot always be met. The system may be safe being tele-


v1.2


operated on the surface of Mars, but perhaps not when close to a group of pedestrians crossing a road on

Earth. Contexts have been used to provide an expanded explanation of goals and strategies to keep the

goals and strategies as concise as possible. Changes to context will potentially invalidate the rest of the

model without further re-evaluation to ensure that the effects of the changes do not have any new

consequences.

Figure 2 : An example of a Context within GSN

4.2.3 Assumptions

Assumptions are unproven points of contention that are assumed to be true. The reader needs to agree

with them in order to agree with that branch of the argument. Not agreeing may cause the reader to

negate a particular strategy in favour of another.

Figure 3 : An example of a GSN assumption

4.2.4 Justifications

Justifications provide an explanation or rationale why an approach has been taken, or why another

seemingly obvious or better approach has not been adopted. They can be used to explain goals and

strategies.

Figure 4 : An example of a GSN justification

4.2.5 Strategies

A strategy in GSN is a declaration of how the argument will be supported, the strategy that is being adopted

to provide further reasoning to the preceding assertions. However, for the purposes of this exercise, they


v1.2


have been used also to propose candidate implementation ‘solutions’ (to real-world operational issues)

for the system itself. Further use of the term solution is avoided in the sense of technical and procedural

solutions to try to reduce confusion with the GSN terminology of an argumentation evidential solution

described in the next subsection. Implementation strategies have been provided since the specifics of how

the system will operate have not been decided at this conceptual stage and it does not make sense to take

the normal GSN approach and strategize over just the argumentation of a system that has not yet been

defined. Strategies that are coloured yellow are singular to the particular issues which they are trying to

address. Blue-purple pastel colour has been used to denote when there is a choice of options available to

address the same issue. These options might be used in combination or may be mutually exclusive. This is

left to the reader to decide in each case. The next stage of evolution would require pruning the unused or

eliminated strategies to define the actual system and expand the detail of what would be deployed. This

strategy selection process is described in more detail in a following subsection.

Figure 5 : An example of GSN strategies

4.2.6 Solutions

Solutions are intended to be the evidential means of proving the assertions which proceed them. They can

take the form of background studies, user trials, detailed design documents, test specifications and their

results or anything else which can be conceived as supporting the arguments above them. Since the GSN

argument produced for this report is at the concept level, other detailed safety cases produced in GSN or

otherwise could potentially be cited in their entirety, or this argument model could be refined to become

those safety cases.


v1.2


Figure 6 : An example of a solution in GSN

4.2.7 Modules and Naming

Modules have been used to separate the model into sections, each of which relate to a particular class of

issue. Each of the modules have been assigned a number which is used to label the items with. This is to

assist with traversing and referencing the model. In some cases sub-modules have been used to keep the

module from becoming unwieldly. As a worked example to illustrate for the Highway Pilot GSN model, the

question could be posed:

“What will happen if a lane needs to be closed, how do I know it will actually work?”

In response to this question the module on lane reallocations is found, then within the goal for lane

closures G1.2 is found, assuming a V2I strategy is preferred, then this is supported by the goals “G1.4 -

Lane Closure Initiation is Failsafe” and “G1.5 - Closure Notifications Are Failsafe” and their supporting

argumentation and a discussion around those strategies, how they will work in practise and what proof is

needed could then ensue. Conversely if the goal “G8.28 - Target Incursion Rate Met” is referenced, then

from its numbering, this can be located within Module 8 for obstructions under the branch for limiting the

occurrence of objects on the road to which the wider debate of prevention versus cure (detection) of

people and animals roaming on highways could ensue.

Figure 7 : An example of a GSN Module

4.3 Using the GSN to Define a Safe and Working System

The GSN is used to set out a conceivable range of candidate technical and procedural strategies. However,

just because various strategies are proposed, this does not necessarily mean the authors agree that all of

the strategies will be able to achieve the desired level of safety and practicality. However, only strategies

that have been deemed to be worthy of inclusion have been considered, even if their inclusion is only

merited to the extent that they should be formally discounted rather than just ignored. It is the job of the

GSN model structure to demonstrate that particular strategies may not really work through the evidence

it requires to support them, or lack thereof. The model presented requires pruning of the used strategies

and the argumentation around each strategy is intended to help with that by showing the evidence that

should be required to give confidence for each strategy.


v1.2


To assist with the pruning of candidate strategies the following section of the US military standard MIL-

STD-882 provides a useful statement for a design safety in section 4.3.4:

“The goal should always be to eliminate the hazard if possible. When a hazard cannot be eliminated,

the associated risk should be reduced to the lowest acceptable level within the constraints of cost,

schedule, and performance by applying the system safety design order of precedence. The system

safety design order of precedence identifies alternative mitigation approaches and lists them in order

of decreasing effectiveness:

a. Eliminate hazards through design selection

b. Reduce risk through design alteration

c. Incorporate engineered features or devices

d. Provide warning devices

e. Incorporate signage, procedures, training, and Personal Protective Equipment.

Often the simplest approach is to solve a problem such as: “tell people not to step into the road in front of

cars”. However, the MIL standard section advises in effect to reverse that thinking and attempt where

possible to eliminate the hazard through design. Only when this is not possible due to real-world

constraints, then start to consider softer measures such as training and education, in effect to treat these

as a last resort instead of a first option.

The candidate strategies that are proposed are to cope with the issues arising from scenarios which

otherwise the automation may not cope with, resulting in hazard or just failure of proper operation, that

is; failure to make sufficient progress along a journey route. Generally, there are some similar reoccurring

themes depicted in the solutions. These are usually choices between:

• Solely vehicle based sensing and perception against having dedicated infrastructure which

may have its own sensing or remote monitoring;

• Implementing a failsafe approach versus a sense and react approach;

• Constrain or control the chaotic elements within the environment or rely upon system

control reactions;

• Rely upon the driver and occupants (when present) to assist with unusual situations or use

more systematic approaches which leave less to the chance of abuse, miss-use or other

human shortcomings.

Even more generally these can be further reduced to just a choice between:

• Use assured infrastructure;

• Use only vehicle systems;

• Rely on the driver/occupant to override/intervene.

The factors which would ultimately determine the solution selection in each case are a function of the cost

and practicality of the ‘best’ solution against whether the ‘lessor’ solutions are still good enough. It should

be remembered that some of the strategies propose the addition of infrastructure or measures which


v1.2


could be reused for other solutions from which the cost and benefit would be shared which may modify

the resultant practicability.

The GSN approach requires evidence that minimum standards of operation are met.

To assist with this determination, the term As Low As Reasonably Practicable (ALARP), has been used in

the GSN text. ALARP is broadly equivalent to SFAIRP (So Far As Is Reasonably Practicable) and ALARA (As

Low As Reasonably Achievable) that are used in some countries. However, SFAIRP could be noted for being

subtly but importantly different to ALARP in that it requires a positive demonstration of due diligence over

and above an outlay of capital. This can help when considering events that are said to be of high

consequence but of low probability (those which often result in court cases), so possibly ALARP might be

better substituted for SFAIRP, but both have the same kind of sentiment that needs to be conveyed. From

an Australian regulatory perspective, they have been summarised as follows9:

• ALARP asks what is the risk associated with the hazard and then can that risk be made as low as

reasonable practicable

• SFAIRP asks what are the available practicable precautions to deal with the identified issue and

then tests which precautions are reasonable based on the common-law balance (of the

significance the risk vs the effort required to reduce it)

ALARP is derived from the Health and Safety at Work Act 1974, which requires:

"Provision and maintenance of plant and systems of work that are, so far as is reasonably

practicable, safe and without risks to health".

ALARP supports the notion that given sufficient time, money, resources and effort, a risk could be reduced

to zero, or in other words, eliminated entirely. The idea behind it is that sufficient measures should be

taken to eliminate risk until the next proportionate step would be in gross disproportion between the costs

and benefits of doing so. If the candidate strategy before the ridiculously too expensive or impractical

option still leaves too much residual risk, then it should be considered that there is currently no viable

proposed option and the system should not be deployed unless or until that changes. This report does not

attempt to postulate what that residual risk level should be, except to advise caution in certain areas where

the risk can be reasonably assumed to be too high. This leads us next to the need to quantify the

acceptance level for risk tolerance.

4.4 Tolerance of Risk

There is also a confidence argument to be made when selecting a particular strategy or approach based

upon ALARP. How good is the knowledge supporting that decision? In the hindsight of a post-accident

investigation or adversarial court case, decisions to limit safety measures, testing and general effort that

9 SFAIRP vs ALARP, Richard Robinson and Gaye Francis, R2A Due Diligence, CORE2014 Conference http://www.r2a.com.au/wp-content/uploads/2015/02/CORE-2014-paper-SFAIRP-vs-ALARP.pdf

http://www.r2a.com.au/wp-content/uploads/2015/02/CORE-2014-paper-SFAIRP-vs-ALARP.pdf


v1.2


appear to have been made mainly on the grounds of cost can appear callous, therefore the notion of

ACARP10 should also be considered:

“…it is important to provide reasons not only for action but also for doing nothing. When an

accident has led to an inquiry or a prosecution, inaction may, in retrospect, give the impression of

negligence, and negligence may be hard to refute. There needs to be evidence, first that it was not

negligence and, second, that inaction was justified. More than that, the engineer should be able to

claim to have been ‘as confident as reasonably practicable’ (ACARP) in each ALARP decision. To

increase the likelihood of favourable SFAIRP judgments, ALARP decisions should be supported by

ACARP arguments.”

Much of the strategy pruning and selection exercise when adopting the GSN technique and applying to

the subject of AVs is a matter of the appetite for risk and the tolerance of road fatalities and serious

injuries. Society accepts that roads are a dangerous part of everyday life, which is balanced against the

convenience of personal travel. However, it is unlikely to be acceptable to suffer any degradation in the

safety record due to the application of automation, particularly as one of the touted advantages of

automation is the reduction in road casualties with the removal of human error. Incidents due to driver

inattention and misjudgement are prevalent and may be significantly reduced by automation. However,

there are new risks emerging from what will appear as seemingly random accidents that are in fact

incidents caused by the insufficiencies of automation. These may be far less palatable to society, seeming

as a fait accompli caused by bad system design rather than a force majeure of circumstance. These new

incidents caused by systemic failings should be considered additive to the existing incidents that take

place. This leads to an important acknowledgement:

Accidents involving automation may involuntarily involve road users who would not have normally

been involved in an accident through their direct actions.

It is strongly suggested by the authors that where possible failsafe measures are implemented, and

where not, the residual risks are considered against the likelihood of hazard occurrence (which may

have to be determined through study once the system has been partially developed) and the wider

benefit to society of realising the full benefits of the feature.

Whilst the cost of a safety measure may at first seem prohibitive, it may be possible to recover the

deployment costs by offsetting them from other areas such as a reduction in crash clean-up and the wider

economic impact of reduced road closures and delays.

Another example is the use of virtual digital signage which may diminish the need to provide and maintain

physical signage and gantries/Variable Message Signs (VMS). This may also lead to changes to signage

location, and content changes becomes more trivial and cost effective with more potential for dynamic

time-based changes.

10 ALARP Explored, Felix Redmill, Newcastle University Computing Science Technical Report Series http://eprint.ncl.ac.uk/pub_details2.aspx?pub_id=161155

http://eprint.ncl.ac.uk/pub_details2.aspx?pub_id=161155

v1.2


A report11 from the H2020 EPCOS project that is looking at the modularisation of aviation safety cases, has

the following to say about the trading of one sets of risks against another:

It should be noted that a change which increases safety risk in one domain is usually difficult or

impractical to justify, even when it significantly decreases safety risk overall.

A debateable ethical issue is that when applied to a feature such as Highway Pilot, a complete inability to

cope with sudden rare events (e.g. an articulated lorry jack-knifing, sink holes, bridge collapses, objects

dropped off bridges on to roads, or animals on the road), cannot be justified by a reduction in general

crashes just because one is more prevalent than the other. Whilst it must be accepted that conventional

manual driving is not without its risks, the limitations of automation in effect enters the vehicle occupants

into a game of chance, which unlike general driving, they have little or no influence over once they have

disengaged from the driving task. The redistribution of risk from one group of would-be manual drivers

who may have been inattentive/incapacitated/incapable when faced with a high risk situation, to a new

group who are selected by fate to suffer a collision, is an ethical issue which requires further thought and

research.

11 Improving European Aviation Safety Approvals, Developing Safe Systems Proceedings of the Twenty-fourth Safety-Critical Systems Symposium, Brighton, UK http://scsc.org.uk/paper_131/06%20Bull%20-%20Improving%20European%20Aviation%20Safety%20Approvals.pdf?pap=987

GSN Outputs – ‘Highway Pilot’ Use Case

v1.2


5 GSN Outputs – ‘Highway Pilot’ Use Case

5.1 Introduction

This section presents the results of the GSN for the Highway Pilot use case.

5.2 Overview

The Highway Pilot feature is considered for a traditional M1 vehicle that is normally manually driven. The

feature can be turned on for motorways and certain dual carriageways which do not contain junctions or

crossing places and which exclude non-motorway traffic. The context explains that when the feature is

activated the driver should always be present and in a position ready to take back control, however not at

short notice. Recent human factors research has shown that it can take between four and forty seconds

for a driver to take back control after an unscheduled Human Machine Interface (HMI) handover request.

Stéphane Feron, a HMI expert at PSA Peugeot Citroën, has coined the term ‘drissenger’ for the role of a

driver who is also part passenger in a supervisory role. He describes the difficulty with determining a

sufficient time margin as12:

The main challenge for level 3 is the take over request with a ‘sufficient time margin’ as the vehicle’s

reaction time is highly dependent of multiple factors and there is no definitive value for the

‘sufficient time’.

It is felt that most of the automotive industry is now moving towards a consensus that sudden handovers

are potentially dangerous for the majority of drivers and therefore are not a realistic strategy moving

forwards for increased automation. The GSN does not provide a time-based definition for how long the

notice period should be, but instead this forms part of the argumentation that a demonstrably adequate

notice period should be given which in turn will have scaling consequences for other system design choices.

In addition, it is assumed that in some instances a handover will be impossible (even if not allowed or

permitted by law) due to the driver falling asleep or becoming incapacitated for other reasons such as a

medical emergency. The main outcome for the feature is that the system must be capable of

deterministically handling anything that can plausibly happen to a vehicle whilst travelling under highway

conditions described by, at the very least, bringing the vehicle to a safe stop in a place which does not

place any road users in danger.

The unintended consequence of this seemingly small requirement change from a short to longer handover

period is that the system (which includes the vehicle, its control software, and any supporting

infrastructure, and procedures) must take on at least an order of magnitude more responsibility for safety

and the resulting system will require far more resilience and assurance surrounding it, which generally

implies more complexity.

The Highway Autopilot GSN has been divided into eight modules as shown in the table below. The

following sections provide a summary of each module.

12 http://blog.carandus.com/2016/03/the-levels-of-autonomy-for-a-car-and-hmi-according-to-peugeot/

http://blog.carandus.com/2016/03/the-levels-of-autonomy-for-a-car-and-hmi-according-to-peugeot/


v1.2


No. Module type Description

HP1 Lane Reallocations This covers lane closures (e.g. due to a stranded broken down vehicle)

and changes in lane usage restrictions (bus lanes, car share lanes, hard

shoulder running).

HP2 Road Etiquette This covers allowing emergency vehicles to pass and appropriate

speed regulation. It could be extended to include traffic merging and

other issues which currently require a degree of discretion and

common sense.

HP3 Lane Rerouting This is for when a lane position needs to be temporarily or

permanently changed, usually during and after roadworks.

HP4 Adverse Weather Strategies to restrict the use of the feature during bad weather,

particularly during the sudden onset of challenging weather when the

system is already active.

HP5 Mechanical Failure To make sure that mechanical failures do no go undetected while the

feature is in use.

HP6 Intervention When external invention is needed either to stop a vehicle or for

speed reduction due to an incident or roadworks.

HP7 Operational

Envelope

Ensuring the feature is only active on the roads it is intended for. It

does not cover other aspects of the control envelope such as stability

and speed regulation.

HP8 Obstructions Strategies for handling collisions with static and dynamic obstructions

in the road.

Table 4 : Highway Pilot module type and short description

The structure of the Highway Pilot GSN is confirmed as shown in Figure 8:


v1.2


Figure 8 : Highway Pilot GSN – Top Level Structure

Drive along designated

'highway' sections of road

autonomously safely

obeying the rules of the

road withouth the need

for driver intervention.

G0.1 - Provide Feature

Conventional M1 vehicle

normally manually driven

by a qualified driver on all

public roads and

highways

C0.1 - Vehicle

Provision for automated

driving intended to be

engaged only on suitable

sections of highway

which allows for the

driver to completely

disengage with the

driving task provided they

remain in the driver's

seat and in a position to

retake control prior to

leaving the highway.

There will be no junctions

(signalled, roundabouts)

except those which

merge to join or exit the

approved highway

sections

C0.2 - Feature Context

All classes of operating

issues have been

identified and sufficiently

mitigated

G0.2 - Identify All Issues

Taxonomy of issues

exercise performed

C0.3 - Issue Taxonomy

J

By identifing all

classes of issues,

assurance is provided

that any given issue

will be covered and

handled in a

predetermined way

J0.1 - Potential Issues

A

Studies and road trials

have suffient coverage to

reveal all types of credible

issue

A0.1 - Road Trial Coverage

Handle sudden onset

mechanical failures

HP5 - mech_failure

Handle spatial operation

envelope

HP7 - op_envel

Handle intervention

needed

HP6 - intervention

Handle adverse weather

conditions

HP4 - adverse_weather

Handle road etiquette

issues

HP2 - road_etiquette

Handle lane Re-rounting

HP3 - lane_rerounting

Handle lane

reallocations

HP1 - lane_reallocations

On-highway supervised

trials performed to

identify real-world issues

Sn0.1 - Trials For Issues

Handle Obstructions

HP8 - obstructions

Key

G – Goal

C – Context

A – Assumption

J - Justification

HP – Highway Pilot

Module

Sn – Solution

Refer to Section 4 for

further explanation of

terminology


v1.2


5.3 Lane Re-allocations (HP1)

This module looks at lane closures and when the permitted use of a lane changes with time, based upon

vehicle type or occupancy. These may seem very different things but they both involve a sudden change

in whether it is acceptable to proceed in the current lane.

Lane closures make a lane unusable to traffic and can be needed with sudden and immediate effect, as

well as for planned activities such as road maintenance. Currently a lane could be closed via a variety of

means, from overhead gantry VMS, or more physical means such as cones placed on the carriageway, or

a large strobe lit mobile signs mounted on highway maintenance vehicles. Lane closures need to be

patently obvious to drivers and the consequences of remaining in the closed lane at full highway speed

can be very high. There is some inevitable overlap with lane rerouting dealt with in another module,

however a distinction has been made between a lane that ceases to exist or be open and a lane which is

gradually shifted laterally to a new position. When considering how this should be done systematically

without the direct assistance of a driver (which must be discounted due to the feature context allowing

for that driver may fall asleep even if not allowed to do so) it quickly becomes challenging once the

consequences of failure are imagined. It can be divided into a matter of directly sensing the environment

or providing some external means which equates to some form of infrastructure. Visual perception can

always fail, so merely sensing cones on the road will not be sufficient in most cases without some other

protection if the vehicle penetrates the coned area. Having the maintenance lorry in-situ is a plausible

alternative since it provides a very recognisable visual reference, and if that fails then it is in effect a large

physical metal barrier which is easily detectable by conventional on-vehicle (Adaptive Cruise Control (ACC)

enabling) radar systems. In this case the vehicle should at the very least stop or change lane even if it fails

to provide a pleasant experience for the vehicle occupants. There may be conditions when this logic is

defeated; what happens after the lorry has been overtaken and there are only cones to indicate a lane

should not be used? Further consideration would need to be given to any additional complexities resulting

in consequential hazards once the vehicle has stopped such as the reaction of following vehicles and the

likelihood of them suffering the same issue. However, it is unfortunately (probably) impractical to deploy

a lorry to the point of every lane closure with almost immediate effect, so another solution must be

considered.

Mapping providers are keen to present map based solutions which often involve what have become

termed Local Dynamic Maps (LDMs). LDMs capture dynamic and transient information about changes to

the road which once detected are then disseminated to other vehicles using V2V or V2I. The idea is that

once a suitably equipped vehicle encounters a change, such as road works or a stranded vehicle, that

information can then be given to following vehicles to allow them to take appropriate evasive action. The

issue is that this approach leaves many things to chance, and assumes that the first vehicle to encounter

the lane closure can itself detect the problem and behave appropriately, so in effect this does not solve

the problem beyond providing non-dependable advisory to other vehicles. However, the general notation

of having a dynamically updated map may be a valid one provided it can be made failsafe. Following this

line of thought leads to an infrastructure approach with some form of synchronous handshaking such that

it will be possible to at least know when the latest information may not have been received. Wireless

communications with infrastructure (e.g. V2I) must be assumed to be able to fail, however unlike

perception (where it is possible to not know what you don’t know) if a transmission is expected, based on

time and/or location, but not received then the system will know it is at risk of there being an unreported


v1.2


change. With this knowledge, preventative action can be take such as attempting a handover to the driver,

or when that fails, attempting to stop in a safe location. This in turn requires that the data loss is detectable

far enough in advance to safely stop before encountering the lane potential lane closure, but these details

can be resolved as part of the requirement cascade of the system design and the definition of its

constraints from which things like optimum safe harbour spacing and capacity can be determined. With

safety ensured, secondary issues such as maintaining communications minimum Quality of Service (QoS)

at peak times requires consideration.

In summary, what this amounts to is having either

• safe to proceed radio beacons which are noticed in their absence;

• or a dynamic map layer with a short expiry time.

Tests would then be needed to ensure that both conceptually and in practise the protection system can

never be defeated, to a level of confidence which is commensurate with the risk of (potentially fatally)

harming road workers, and people in stranded vehicles are well as the occupants of the vehicle hosting

the feature.

The next consideration within this module is when the allowed use of lane changes with time such as for

bus lanes, high occupancy lanes or hard shoulder running. The means to handle lane use changes divide in

a similar way to lane closures. Machine vision of conventional road signs could be relied upon (requiring

optical character recognition), but this is likely to be prone to failure. A map based solution is again a

natural solution as time restrictions could be added as easily as speed limits to existing maps as an

attribute. The difficulty arises at the point where changes are made to the lane regulations. This can be

managed using map expiry times and aligning regulatory changes to map expiry times to ensure the

changes are fully propagated. A map update failsafe might not be needed in this case (perhaps with the

exception of hard shoulder running) but if it has been implemented for other reasons it could be reused

to prevent the feature being used without the latest information for the intended route.

The Highway Pilot Lane Reallocations module is shown in Figure 9:


v1.2


Figure 9 : Highway Pilot GSN – Lane Reallocations Module (HP1)

Handle lane reallocations

G1.1 - Lane Reallocations

Handle lane closures

G1.2 - Lane Closures

Handle time-based

changes to lane useage

for no-car (bus) lanes

and high occupancy (car

share) lanes and hard

shoulder running

(emergency lane use as

a normal lane)

G1.3 - Lane Restrictions

Machine vision of normal

visual cues (cones, gantry

VMS signs, rear of lorry large

sign)

S1.2 - Use Visual PerceptionV2I authorised operator

(Police/DVSA) can effect

an on-demand lane

closure which will in turn

update the vehicle's local

dynamic map on or before

approaching the vicinity of

the lane closure

S1.1 - Use V2I

Time based restrictions

added as metadata to

vehicle map. Occupancy

HMI provided to the driver,

or lanes are avoided when

possible

S1.3 - Add To Digital Map

Tests of adherance to

lane restrictions

Sn1.5 - Practical Tests Highway authority map update

procedures

Sn1.6 - Map Update Procedures

Lane restictions are always

met

G1.7 - Lane Restrictions Met

The map is updated with

changes ahead of time.

Metadata expiry time/date

used. If data is not current

then lane is avoided or

feature is inhibited entirely

S1.5 - Use Map Expiry Time

Tests of map data timeout

handling to preclude unintended

consequences

Sn1.7 - Map Expiry Consequences

Map data expiry method is robust and

does not lead to unreasonable outage of

the feature or strange road behaviours (i.

e. if a restriction is removed and the ego

vehicle is left 'out in the middle lane'

creating a new hazard)

G1.8 - Map Expiry Works and is Practical

Visual cues or physical obstructions

are always detected in time to safely

react to them under all conditions

when the feature is operable

G1.6 - Visual Cues Will Always Work

Stationary lead vehicle

detection and braking tests

Sn1.3 - Brake Reaction Tests

Multi-condition tests of

vision performance

Sn1.4- Condition Tests

Implemented procedures have sufficient

locational accuracy and timeliness and

are synchronous so that the operator is

given positive confirmation when a lane

closure is in effect

G1.4 - Lane Closure Initiation is Failsafe

Vehicles cannot operate the feature or

continue to operate the feature in the

vicinity of the lane closure without

receiving a closure notification dynamic

map update

G1.5 - Closure Notifications Are Failsafe

A

This measure will be

actioned in addition to

any normal physical

barrier (formed by an

emergency/incident

vehicle or otherwise)

A1.1 - Physical Fallback

V2I beacons are periodically

located in known map

stored locations to publish a

'safe to proceed' signal to

passing vehicles. The

abscence of a signal should

be used to deactivate the

feature in reasonable time

for a hand over to take place

before a lane clousure is

encountered

S1.6 - Sliding V2X Geofence

A safe distance from the lane closure cannot

be breached at any time with the feature

active

G1.9 - Safe Lead-up Zone Is Not Breachable

Tests of adherence to

lane closures

Sn1.8 - Practical Tests Procedures or system design to

ensure sufficient notification

distance/time before

encountering a lane closure

Sn1.9 - Procedures and Design

Study of procedures

(beacon layout,

expectations upon the

operator including a

human factors

assessment if needed)

Sn1.1 - Procedure StudyV2I Comms design and

availability tests

Sn1.2 - In Situ Comms Tests

A

Actioning of the lane closure could

be performed by a control center

instructed by the operator, or

directly by the operator through a

V2I linked device. In either case,

positive confirmation of the closure

should be given to the operator

before they should consider the

closure to be active

A1.3 - Positive Confirmation Given

Machine vision of normal

visual cues (cones, gantry

VMS signs, rear of lorry

large sign)

S1.4 - Use Sign Recognition

AUnlikely to be practicable

A1.2 - Perception Limitations

A

The beacons can provide a course absolute dead

reckoning, however vehicles must be capable of a level

of localisation to notice the abscence of a beacon

where one is expected

A1.4 - Ego vehicle localisation minimum performance

How map updating is achieved is

not stated, but provided there are

no serious safety consequences,

this could be achieved co-opertively

rather than synchonously if the user

accepts the responsibility

C1.1 - Map Updating Responsibility

Defined as a lane closure

or lane restriction (which

include bus lanes, high

occupancy vehicle lanes,

and hard shoulder

running)

C1.0 - Lane Reallocations

Key

G – Goal

C – Context

A – Assumption

J – Justification

S – Strategy (yellow = singular, blue = one of several options)

Sn – Solution

Undeveloped

Refer to Section 4 for further explanation of terminology


v1.2


5.4 Road Etiquette (HP2)

This module has been used to address emergency vehicle procedures and the normal regulation of vehicle

speed.

5.4.1 Emergency Vehicle Passage

Allowing emergency vehicles under blue light operation to pass is currently handled somewhat awkwardly

by current practise as different drivers will react differently and with the best of intentions. Due to a lack

of overall coordination this can lead to emergent situations that can make the progression of the

emergency vehicle worse rather than better. Many drivers in an urban setting choose to mount the

footway or on a highway (through an emergent consensus) may enter the central reservation zone to help

provide a central corridor for the responding vehicle to pass through. This may be technically illegal, or a

breach of the rules of the road, but it is unlikely that any court would see it as being in the public interest

to prosecute. The Highway Code Rule 219 gives further guidance about predicting the path of the

emergency vehicle and pulling over to the side of the road without breaking any rules of the road or

endangering other road users.

How this is handled does probably not have any direct safety implications for road users, but there are

indirect implications if for instance the ambulance is delayed from arriving at the scene of a person with a

medical emergency which could mean life or death for that individual. The lack of an explicit set of rules

presents a difficulty in writing software to take action to let emergency vehicles pass. It could be left to

the discretion of the driver to take back control or provide instruction through a user interface, or if that

is ruled out then a systematic approach is needed. The system can be left to ‘notice’ the situation either

though the normal cues which a human driver uses, or directly through a wireless V2I / V2V notification.

Once the approaching vehicle has been recognised, it could still be left to the driver to take action once

prompted, or further left to the system to decide what action to take. The latter option is difficult to

develop without refinement to the Highway Code or better definition of what the procedure should be.

Scenarios can be enacted under controlled conditions to develop and test the resulting system.

5.4.2 Speed Regulation

Speed regulation is a seemingly obvious and necessary condition for an AV to function, but one which has

not received much attention in open forums. Not exceeding the speed limit is probably a given, and

something that the DfT has stated as an expectation of AVs, but the speed limit is just that, a limit, not a

target speed appropriate for all conditions and sections of a road. Driving at or below the speed limit at a

rate which ensures passenger comfort and vehicle stability seems to be the natural solution. How this is

determined is less obvious. Setting a target speed for normal conditions which could be applied to a digital

map as an attribute is one strategy, or varying the speed limit could be another. A vehicle specific offset

could then be applied to the target speed to allow for model specific capabilities and driver/user

preferences. Handling larger speed offsets for degraded weather conditions presents a more challenging

issue. This could be left to the individual system implementers to decide how to sense conditions and apply

offsets, but the burden of proof that their methodology works should be maintained prior to the

deployment of the vehicles rather than left to a future court case after an incident.


v1.2


It should also be noted that current Electronic Stability Control (ESC) systems are provided to assist the

driver in not losing control of the vehicle and are not an absolute guarantee of stability under all conditions.

Continental state13:

Without enough friction between tyres and road (good “grip”), there is no way of keeping a vehicle

under control. Active safety systems such as ABS and ESC will help in situations when emergency

braking or imminent skidding put a driver’s skill to the ultimate test. However, even such valuable

systems as ABS and ESC will only react, when the vehicle is already in danger of getting out of

control. Realistically it is entirely up to the driver to estimate whether there is enough grip to allow

for the vehicle’s current speed.

Once the driver is removed from the loop, the bar is substantially raised for stability to be guaranteed,

which is quite difficult to achieve for all road conditions. Driving at a suitably slow speed such that the

vehicle is not close to the limits of its traction is one way, but can be a self-defeating argument since the

limit of traction is not always known in advance and its estimation is a reactive part of the stability control

system, so the ‘suitably safe’ speed is not always known in advance of a problem. If transitioning from a

salted section of road to a section of snow covered road, then this estimation may be incorrect until

instability (wheel slip or yawing) is sensed. The European Sixth Framework Programme Project FP6-2004-

IST-4 called FRICTI@N has made some progress with improved road surface friction coefficient

estimation14. However, although this improves greatly upon what is currently in production, it still only

offers measures which are reactive to the road surface which are currently ‘under foot’ to the vehicle with

no anticipatory ability of what is ahead to allow pre-emptive slowing down before hitting a patch of ice.

The Highway Pilot Road Etiquette module is shown in Figure 10:

13 http://www.continental-corporation.com/www/pressportal_com_en/themes/press_releases/3_automotive_group/interior/press_releases/pr_2010_10_12_sensorfusion_en.html 14 FRICTI@N Deliverable 13 - Final Report: http://friction.vtt.fi/FRICTION_FinalReport_D13.pdf

http://www.continental-corporation.com/www/pressportal_com_en/themes/press_releases/3_automotive_group/interior/press_releases/pr_2010_10_12_sensorfusion_en.html




v1.2


Figure 10 : Highway Pilot GSN – Road Etiquette Module (HP2)


issues

G2.1 - Road Etiquette

Allow emergency vehicles to pass

G2.2 - Emergency Vehicle Passage

Rely upon driver to notice

and take the appropriate

action

S2.1 - Manual Intervention

V2I/V2V Broadcast

S2.6 - V2X Broadcast

AV will notice conventional

cues (sirens and lights)

S2.7 - Conventional Cues

AV will take necessary

steps to allow passage

S2.2 - Systematic Passage

There will always be a vehicle system awareness

of emergency vehicles being obstructed

G2.5 - System Awareness to Emergency Vehicles

Inform driver to assess if action

is required and take over if

needed

S2.10 - Alert Driver to Takeover

Detection method is

sufficientely robust and works in

practice and leads to

appropriate action being taken

G2.8 - Detection Method Works

Take appropriate action (lane

change/merge, slow down to

assist over-take)

S2.11 - System Takes Action

Driver will be able to take the

appropriate action in a timely

manner

G2.10 - Driver Timely Response

User trials

Sn2.3 - User Trials

The ego vehicle will never

become an

unreasonable

obstruction to emergency

vehicles

G2.11 - Never Obstruct

Proving ground

and public road

trials

Sn2.4 - Road Trials Test case library

Sn2.5 - Test Case Library

A

Ultimetely the driver will still be

available if in a complex

scenario the feature is unable

to negotiate a traffic merger, or

otherwise becomes an

unreasonable obstruction for

any significant length of time

A2.5 - Driver Always Available

The Highway Code currently states

that no rules of the road can be

broken to allow emergency

vehicles to pass, however many

drivers will use their discretion.

Such actions might include use of

hard shoulder, crossing of solid

markings, mounting of kerbs etc.

C2.2 - Discretionary Rule Breaking

The majority of drivers will be able to safely take

back control in a reasonable amount of time

such that the progression of emergency vehicle

is not made worse than at present

G2.4 - Manual Takeover is Effective in Practice

Studies and tests of

emergency vehicle

progression

Sn2.1 - Progression Tests

Driver behavioural

study

Sn2.2 - Driver Study

Regulate speed

appropriately for all

conditions of operation

G2.3 - Speed Regulation

Map based target speed segments or

speed profiles and apply vehicle and

weather condition specific offsets

S2.5 - Vehicle and Condition Speed Offset

Speed variation for unimpeded driving

within the legal speed limits, slowing

for bends or areas with reduced

visability etc

C2.2 - Speed According to Conditions

A

Map based speeds are suggested

nominals against which attributes can

be set to indicate the reason for

deviations from the speed limit

A2.3 - Speed Nominals from Map Data

Interpret the road ahead and local

conditions then apply heuristics

S2.4 - Use Perception and Heuristics

Vehicle is kept well within its control

and stability margins without relying

upon stability control interventions

G2.6 - Vehicle not driven 'on the edge'

Vehicle meets generally accepted

percepions of suffieciently safe,

prudent and comfortable

progression rates

G2.7 - Progression Rate Feels Safe

User trials

Sn2.7 - User Trials

Proving ground

and road trials

Sn2.6 - Road Trials

Roads deemed suitable for

use of the feature are safe to

travel at the speed limit under

normal conditions, and

existing speed limits are

adjusted if required

S2.3 - Use Legal Speed Limits

Dynamic speed limits are

applied to accomodate local

conditions

S2.8 - Dynamic Speed Limits

ACriticallity of map speed data?

A2.2 - Map Speed Data Correctness

Vehicle will make its own

assesment of the road

conditions and apply a speed

correction

S2.9 - Perception and Heuristics

A

A control centre will be monitoring the

road conditions and updating speed

limits accordingly

A2.4 - Continuous Dynamic Monitoring

All real-world conditions are

handled

G2.9 - Real World Conditions

A

May present issues for manually

driven vehicles?

A2.1 - Speed Limit Granularity Issues

Emergency and Incident Support vehicles. You should look and listen for

ambulances, fire engines, police, doctors or other emergency vehicles

using flashing blue, red or green lights and sirens or flashing headlights,

or traffic officer and incident support vehicles using flashing amber lights.

When one approaches do not panic. Consider the route of such a vehicle

and take appropriate action to let it pass, while complying with all traffic

signs. If necessary, pull to the side of the road and stop, but try to avoid

stopping before the brow of a hill, a bend or narrow section of road. Do not

endanger yourself, other road users or pedestrians and avoid mounting the

kerb. Do not brake harshly on approach to a junction or roundabout, as a

following vehicle may not have the same view as you.

C2.1 - Highway Code Rule 219

Road etiquette covers the

many unwritten and

unspoken informally

implied rules of the road

such as offering and

reinquishing right of way

and proportionate

modulation of vehicle

speed to the prevailing

conditions and perceived

surrounding risks. The

coverage here is far from

exhaustive and requires

further expansion for

completeness

C2.0 - Road Etiquette

Key

G – Goal

C – Context

A – Assumption (red = concern over assumption, further research needed)

J – Justification


Sn – Solution



v1.2


5.5 Lane Rerouting (HP3)

Lane rerouting is when a lane position needs to be temporarily or permanently changed, usually in and

around roadworks. How this affects the vehicle depends largely on how the vehicle normally tracks its lane

position. Currently two methods are prevalent firstly the use of image recognition of the lane marking lines

as is currently used for ADAS features such as Lane Keep Assist (LKA) and Lane Departure Warning (LDW).

This can work well enough as a driver advisory on highway sections of road since the lane markings are

usually well maintained and clearly visible due to sufficient vehicle separation (from the required braking

distances). When traffic queues form, the traffic tends to close up and the lines are not always visible.

Tracking the vehicle ahead under these conditions is a partial solution which is used, but that assumes that

the vehicle ahead does not have the same problem and is following the same route. There have

consequentially been reports of vehicles unintentionally and unexpectedly following the lead vehicle off

the highway onto another road due to this deficiency.

A second approach is to use medium to high fidelity digital maps and by locating and orientating the vehicle

on the map to a high degree of precision, the vehicle is kept in the real-world lane by driving in a virtual

lane on a map. Obviously, this relies on ensuring the virtual lane on the map is kept in alignment with the

physical one on the road. This has placed a high degree of responsibility on the map being up-to-date and

accurate as well as the real-time positioning on the map being equally up-to-date and precise. Whether

this can be done to a level of confidence high enough to be assured for high speed driving remains an open

issue. Failsafe mapping and localisation interlock are both required unless substantial risks to all road users

are to be tolerated. They don’t need to always work, but the system does need to know when the

confidence in either has dropped over time in order to take action such as handing over control to the

driver or stopping the vehicle somewhere safe. If the safe stopping location is in question, as a

consequence of map obsolescence say, then knowing where a safe location is may become a self-defeating

argument without a fall-back procedure.

Similar arguments to lane reallocations can be made using maps with expiry times or safe-to-proceed

wireless beacons which can provide a basic level of localisation coupled with the assurance that the latest

map information is being applied. It could be argued that precise localisation is more critical for keeping in

lane than for lane closures as these can be set further ahead of physical obstructions than the width of a

lane. However, it is unlikely that one would be needed without the other, this is if localisation is needed

to know where a lane closure is then it will also be needed for lane locations and hence the latter sets the

requirement for localisation performance. Many different localisation strategies are being proposed by

researchers and technology companies. However, no clear candidate has emerged so far. Rather, it may

be being assumed that some fusion of all the available techniques will provide full coverage. This may not

be the case and it may need to be explicitly resolved such that there are no coverage gaps that could result

in a perfect storm. This should be done by design and not just left to a ‘try it and see’ approach to testing.

The Highway Pilot Lane Rerouted Lanes module is shown in Figure 11:


v1.2


Figure 11 : Highway Pilot GSN – Rerouted Lanes Module (HP3)

Handle rerouted lanes

G3.1 - Rerouted Lanes

A

Contraflows must have a temporary

median barrier as the AV feature (as per

the top level context) does not support two-

way traffic, i.e. not just a row of cones or

bollards

A3.2 - Contraflows Have Physical Barriers

Reliance upon perception

of physical (painted) lane

markings

S3.6 - Use Road Markings

A

Technical limitation that

ground painted lines are not

always visible in close

following traffic therefore the

ego vehicle may inadvertently

follow a lead vehicle off at an

exit

A3.1 - Lead Out Of Lane Risk

Rerouted lanes are clearly

line marked with no exit

routes and pre-existing

incorrect markings are

adequately masked

G3.4 - Clear Lane Markings

AVs use updated digital

mapping which includes

rerouted lane details

S3.1 - Use Lane Static Mapping

Vehicle can only proceed

with current and correct

map data (Map data

interlock required)

G3.3 - Map Data Interlock

Map data has expiry time.

A new map is required

every hour/day over V2I

S3.4 - Time Limit MapsUse V2I beacons to provide

dead-reckoning and update

to new local map. The

feature will not stay active

without a 'safe to proceed

with map version = X' from

nearest expected beacon

S3.5 - V2I Map Zone Checks

V2I comms have a

sufficient QoS to not

unreasonably introduce

unnecessary feature

drop-outs

G3.8 - V2I Sufficient QoS

Interlock failures do not force an

unreasonable hand-over to the driver

G3.9 - Safe Map Version Failure Handover

Comms tests, peak-load

situations

Sn3.5 Comms QoS Tests

Study of required beacon

locations to provide sufficient

granularity/coverage

Sn3.6 - Beacon Coverage Study

The ego vehicle can never

proceed into a lane altered region

using the feature after an interlock

failure

G3.10 - Map Version Enforcement

Proving ground tests

of missing beacons

and expired map data

Sn3.7 - Failsafe Tests

On-road real world

robustness and

performance tests of road

marking perception

Sn3.8 - Road Marking Tests

An expired map can never be

used by the feature to proceed

into an a lane altered region

G3.6 - Expired Map Enforcement

Handovers due to an expired map

are done without an unreasonable

hand-over to the driver

G3.7 - Safe Expired Map Handover

A

Security of map updates

are not considered

(tampering with map

data)

A3.3 - Map Data Security

SiL/HiL rig, proving ground and

road tests

Sn3.3 - Map Enforcement TestsStudy and tests of

timely notification of

feature outage

Sn3.4 - Handover Study

Localisation system can always be relied

upon to a sufficient resolution such that a

lane altered region is not entered into by

assuming an incorrect map segment is

current

G3.2 - Localisation Accuracy and Resilience

Argument over localisation

system performance

S3.3 - Localisation Performance

Localisation system always meets

performance targets required for regions

allowed to have lane alterations (GNSS,

dead reckoning etc)

G3.5 - Localisation Performance Targets

Tests of localisation system against

ground truth under varying conditions of

GNSS outage and performance

Sn3.1 - Localisation Performance Tests

Study of the required localisation

performance to guarantee a reasonably

timed handover before approaching a lane

altered region

Sn3.2 - Performance Requirements Study

Road marking inspection

and maintenance

procedures and schedule

Sn3.9 - Road Marking Repair

Study of road marking

wear and degredation

rates

Sn3.10 - Wear Rate Study

The accuracy and resilience is

supported by forming argument

for the performance of the

localisation performance

C3.1 - Localisation Performance

When lane markings are

altered to get vehicle to

follow a new or modified

path. Examples include

temporary traffic

management measures

to create narrow lanes

C3.0 - Rerouted Lanes

Key

G – Goal

C – Context

A – Assumption

J – Justification


Sn – Solution



v1.2


5.6 Adverse Weather (HP4)

The basic principal is to inhibit the feature during bad weather. The focus in this module is on the ability

of the system to continue sensing and understanding its environment rather than keeping control of the

vehicle due to poor traction, but the containment measures could be similar for both cases. What bad

weather actually means and how bad it has to be depends upon the capability of the system to cope with

various conditions that may affect its performance, particularly during safety critical situations. It might be

conceptually simple just to prevent the feature being turned on during bad weather, but consideration is

needed for when the feature is already in use and the weather starts to suddenly deteriorate. Further to

this, it should not be forgotten that the feature context provides for the fact that the driver may have

fallen asleep or have become incapacitated whilst the feature is active, so a handover may not be possible

and just stopping might be particularly dangerous especially in road conditions where there is reduced

visibility and reduced traction.

Again, the choices emerge for preventive measures (weather forecasts), relying on the driver’s discretion,

or a fully systematic approach whether using a standalone infrastructure support method. Part of the

problem rests with detection. Infrastructure monitoring and support would be one way, with the benefit

of being able to see the conditions far ahead in time to stop or handover gracefully, but there is also the

risk that very localised weather events go undetected. If the driver retains responsibility and remains alert

and awake, they will still have been physically disconnected from driving the vehicle so their proprioceptive

feedback from the vehicle controls is not in place to know that conditions are making driving difficult, and

they may also not be able to judge when the system is or is not able to cope with the prevailing conditions.

Some people would be cautious and others would use their desire to arrive at their destination in good

time as cause to just take a chance and proceed with their journey. Prosecuting after the fact may not be

helpful or enough of a deterrent given the potential for uncertainty around the decision to stop the feature

and the burden of proof with determining who/what was driving. Fully systematic detection and reaction

for all plausible adverse weather conditions is quite a challenge, but if it can be achieved there are still

practical considerations to be made. There is the possibility of stranding the driver (and passengers) on

the road in a safe harbour or in remote areas in poor weather conditions, if the feature has been permitted

to drive them into conditions that are beyond their own ability to continue driving, and may require their

subsequent rescue, so suitable provisions or warnings may need to be made.

The Highway Pilot Adverse Weather module is shown in Figure 12:


v1.2


Figure 12 : Highway Pilot GSN – Adverse Weather Module (HP4)


conditions

G4.1 - Adverse Weather

Machine vision of VMS

warnings

S4.3 - VMS ReportingV2I Comms used to nofify

system and/or driver of

current or impending poor

weather conditions

S4.4 - V2I Reporting

Rely upon driver's due

diligence

S4.5 - Driver's Discretion

Don't operate the feature when

weather conditions are too severe

to do so safely

S4.1 - Inhibit During Bad Weather

Feature is always deactivated and

inhibited when weather restricts its safe

useage

G4.2 - Can Never be Used in Bad Weather

Robust sensing of

weather conditions by

vehicle

S4.2 - On-vehicle Sensing

Real-time monitoring and

reporting of weather covers all

defined highway routes to

protect against localised

weather being unreported

G4.4 - Full Monitoring Coverage

Year-round tests of

monitoring and reporting

system

Sn4.1 - Monitoring Tests

Defined route

coverage analysis

Sn4.2 - Route Analysis

On-road tests of

communications link

and coverage

Sn4.3 - Comms Tests

V2I system provides sufficient

coverage to protect against localised

weather being unreported

G4.5 - Sufficient Reporting FrequencyAll extreme weather conditions which present

a risk to the safe operation and performance

of the system can be sensed and detected

G4.3 - All Adverse Conditions are Detectable

Argument over the weather hazard

types

S4.7 - Weather Types Argumentation

Road surface flooding

can be detected

G4.8 - Flooding Heavy precipitation (inc. snow

and hail) and aerosols (mist,

spray, fog, dust) can be detected

if degrading sensing

performance below an

acceptable minimum

G4.9 - Precipitation and Aerosols

Snow, ice or hail

accumulation on road

surface

G4.10 - Frozen Deposits

Diagnostic of sensor

returns. Sensor fusion

disparity

S4.11 - Sensor Diagnostics

Traction control, ABS, ESC

activation patterns

S4.12 - Stability System ActivationMissing lane markings, ground plane

positioning, traction issues and other

cues

S4.10 - Use Physical and Visual Cues

Driver will be able to judge when the

weather conditions are inappropriate to

use the feature on their particular

vehicle and is able to accept the risks

and responsibility for any errors in

judgement

G4.6 - Driver's Judgement is Sufficient

Training and

awareness

programme

Sn4.5 - TrainingUser trials and

customer clinics

Sn4.4 - User Trials

A

VMS Coverage is

sufficiently widespread to

prevent useage in

inappropriate conditions for

any significant length of

time or distance

A17 - VMS/V2I Granualarity

High winds

G4.11 - Wind

Inertial measurements and

steering path correction entropy

thresholds

S4.13 - Steering Corrective Effort

Monitor and close affected roads when weather condition

thresholds are exceeded. Vehicles already on affected roads

will be directed to leave at the next exit or go to the nearest

refuge place.

S4.9 - Systematic Road Closure During Extreme Conditions

Defined highway routes have their

full extents actively monitored and

will be closed before any

significant weather related hazards

can occur

G4.13 - Preventative Road Closure

Drivers will not become

stranded in their vehicles on

approved routes

G4.15 - No Stranded Drivers

Manual driving will still be possible

after a handover has taken place

subject to conventional weather

imposed limitations

S4.16 - Manual Driving Still Possible

Monitor the extents of defined highway routes and put

appropriate dynamic restrictions in place

S4.6 - Remote Dynamic Monitoring and Control Restrictions

Variable speed limits and lane closures according to the

prevailing conditions

S4.8 - Systematic Variable Speed Limits and Lane Access

All weather conditions affecting safety

and performance can be handled by

applying restrictions in good time to

changes in weather whilst maintaining

a reasonable QoS

G4.7 - Sufficient Reaction Performance

Adequate protection can be provided

through the timely detection of and

response to adverse conditions

G4.12 - Sufficient System Reponsiveness

Argument over detection

mechanisms and road

infrastructure

S4.15 - Detection Argumentation

Proposed measures are

complete and adequate

enough to keep QoS high

and reduce risks to ALARP

G4.17 - Risks Kept to ALARP

Design and test

measures of weather

detection systems

Sn4.10 - Detection Design

Response time and

coverage analysis to

determine worst

case exposure to

weather events

Sn4.9 - Gap Analysis

Argument over the effectiveness of vehicle

detection and responses to variable speed

limits and lane closures

S4.14 - Detection and Response Argument

Vehicle is always kept within its safe

operating limits of the feature for the

prevailing weather conditions on

defined highway routes

G4.16 - Kept Within Operating Limits

Test of vehicle performance around

defined weather condition limits

Sn4.7- Weather Performance Tests

Test of systems's detection

performance of variable speed

limits and lane closure

Sn4.8 - Restriction Detection TestsThere should not be a form of entrapment

caused by a false sense of security during

deteriorating weather conditions while using

the feature and not directly experiencing that

driving is becoming challenging due to the

prevailing weather

G4.18 - Driver Not Insulated from Conditions

Strategic analysis

Sn4.12 - Strategic Study

Testing of detection of

weather conditons

close to agreed

performance limits for

vehicle

Sn4.6 - Detection Tests

Detection measures are

sufficiently robust

G4.14 - Detection is Robust

J

This is to be further developed

and expanded with the

particular implementation

specifics once they are

decided or known

J1 - System Specifics Needed

A

Vehicle limitations are

assumed to be

nominally the same for

all brands and models

A1 - Vehicle Limitations A

A co-operative feature inhibit could

be used instead in the same way,

but depending upon performance

thresholds this may occur at the

same time as a road is deemed

impassable regardless of the use

of the feature

A1 - Close Road or Inhibit Feature

A

This does not include being

trapped by the combination of

traffic volume and weather

conditions

A2 - Traffic Volume Exception

User trials

performed during

degrading weather

conditions

Sn4.13 - User Trials

A

The ability of each driver to

drive in adverse weather will

vary largely from driver to

driver (age, experience,

other factors). Need to avoid

the feature handing over at a

point where the driver is

unable to reach a safe

refuge and requires rescue

A3 - Driver Ability Variability

Adverse weather covers

challenging

environmental conditions

which can affect visibiltiy,

the road surface and the

controllability of the

vehicle. Examples

include rain, fog, snow,

ice, bright sunshine,

flooding and winds etc.

C4.0 Adverse Weather

Bad weather is defined as any

of the adverse weather

conditions which are of

sufficient servierity to affect the

safety and normal operation

of the vehicle while the feature

is operational and has been

given control of the vehicle

C4.1 - Bad Weather Definition

The strategy to support system

responsiveness is to present an

argument that the detection

mechanisms can be proved to be

sufficient

C4.2 - Detection Strategy Arguments

Key

G – Goal

C – Context

A – Assumption

J – Justification

S – Strategy (yellow = singular, blue = one of several options, red =

concern over option, further research needed)

Sn – Solution

Undeveloped



v1.2


5.7 Sudden Mechanical Failure (HP5)

This module deals with mechanical failures. The reason for limiting to mechanical failures is that electronic

and software failures are dealt with during the development and testing of the system. The base vehicle is

otherwise assumed to be well maintained and not an issue which may not always be the case. As with the

rest of the vehicle, existing vehicles have been developed with the reasonable assumption that there is a

driver in control and mechanical failure modes analysis will concentrate on being able to bring the car

safely to rest in the event of a component failure. It will also be assumed that the driver will notice the

failure from degraded performance or increased noise/vibration, strange handing etc. If the driver is not

physically driving anymore for extended periods of time, then a mechanical fault could develop and go

unnoticed, not least due to the lack of proprioceptive feedback to the driver when disconnected from the

main driving controls.

What the module aims to achieve is to eliminate failures that could be dangerous and go unnoticed to

both the driver and the system when the system is in control. Vehicles currently have limited or no ability

to self-diagnose or perform pre-failure prognostics of mechanical faults, with tyre pressure monitoring

being the only possible exception. Vehicles are generally highly reliable compared to previous decades, so

there may not necessarily need to be any action taken, but it should also not be left to chance and

component failure rates should be reconsidered against the automation system’s ability to recognise them

and respond appropriately when needed. There are two basic approaches, the first is simply mitigation by

regular inspections, and the second is to increase/improve the on-board detection capabilities, which may

require additional instrumentation on the vehicle which is not currently needed. Taking the first approach,

the current MOT check may still be adequate, but the MOT interval may need adjusting and depending

upon the analysis this could be extended in the extreme all the way to something equivalent to aircraft

pilot pre-flight checks. In practise, expecting people to perform their own checks may be unrealistic, even

if they were as trivial as checking tyre pressures once per day. Competency would inevitably lead to neglect

of these checks in everyday life, but it may also lead to a market pressure for vehicles to be sold which can

self-check to a higher degree. Fleet owned and operated vehicles could be checked as part of the

operational procedures as part of an operating license, but for this would be more appropriate and

applicable to a run empty service such as the Urban Pilot use case described in section 6.

The Highway Pilot Sudden Mechanical Failures module is shown in Figure 13:


v1.2


Figure 13 : Highway Pilot GSN – Sudden Mechanical Failures Module (HP5)

Handle sudden onset mechanical

failures

G5.1 - Sudden Mechanical Failures

Inspections and testing

S5.1 - Prevention

Latent failures are reduced to

ALARP through regular

inspections and testing

G5.2 - Inspection and Testing

A

The MOT Test is of sufficient

scope, depth and frequency

A5.1 - MOT Test Sufficiency

Breakdown and incident

statistics

Sn5.1 - Breakdown Stats

On-board diagnostics and

prognostics

S5.2 - Detection

The presence of all

mechanical faults which

can have a significant

influence on directional

control or stability can be

detected or predicted in

time to reach a

controllably safe

condition

G5.3 - Fault Observability

High level vehicle

mechanical FMEA shows

failure consequences,

preventions, and

mitigations

Sn5.2 - Vehicle FMEA/FTA

Fault detection and reporting

system description,

requirements and verification

and validation documents

Sn5.3 - System Design Docs

The onset of mechanical failures can be

more difficult to detect than electronic and

systems faults as it often requires

noticing subtle cues such as an increase

or change in vibration and noise levels

that whilst may be apparent to a human

driver (while driving) are undetectable to

an automated system without explict

condition monitoring measures in place

C5.1 - The Need for Condition Monitoring

Tests of failures that are

handled by directly controlling

the vehicle to a safe condition

e.g. burst tyre

Sn5.4 - Induced Failure Tests

Key

G – Goal

C – Context

A – Assumption

S – Strategy (yellow = singular, blue = one of several options

Sn – Solution



v1.2


5.8 Intervention (HP6)

There will at times be a need for external intervention to change the speed of a vehicle (for roadworks) or

to bring it to a complete stop. Dynamic changes to speed limits can be dealt with in a similar way to lane

closures and lane rerouting, whether by visual perception or through an infrastructure means.

A vehicle may need to stop as part of a road block for all vehicles or as part of Police and Driver and Vehicle

Standards Agency (DVSA) stop procedures for individual vehicles. An assumption has been made that a

rolling road block or thereafter a full road block will be initiated from in front of the vehicle. Conversely, in

the first instance, individual stops will be initiated from behind by a following vehicle. For road blocks, it

could be treated as a multi-lane closure for approaching vehicles, but it will first need to be initiated to

break the existing flow of traffic using a stop manoeuvre. When the stop manoeuvre is performed, it will

be up to the vehicle systems to recognise this by some means.

Stopping just one vehicle is more challenging than an indiscriminate road block as even if some remote

mechanism is provided other than the usual visual signals (flashing of lights or a Police Stop sign), the

initiator (Police/DVSA) still needs to identify the particular vehicle they wish to halt either via its location

or registration or some other means. Authentication to prevent malicious spoofing of the stop mechanism

remains a concern, particularly for visual signs which could easily be replicated, remembering that just

those signs and not a convincing replica of a full Police car would be needed to trick the system in to

stopping. For this reason, the author suggests that a guiding principal should be to leave ultimate control

with the driver as far as possible to allay people’s concerns where law enforcement could just incapacitate

any vehicle on a whim. The converse situation where the driver may become incapacitated or somehow

trapped in a moving vehicle needs to be addressed, along with the genuine occurrences of uncooperative

criminals who need to be stopped for law enforcement and public safety reasons. A set of strategies are

required which cater for these opposing concerns.

The decision to stop could be left as it currently is: entirely with the driver. However, due to the previously

mentioned concerns about a sleeping, otherwise incapacitated, or just unobservant driver, there still

needs to be a way to stop a would-be ‘runaway’ vehicle. The vehicle could be stopped in theory by just

driving in front of it and slowing down, but there is always the risk it may just overtake, so two Police

vehicles may then be needed to box it in. A better solution is for the system to be notified of the stop

‘request’ and try to inform the driver via a user interface. If the driver remains unresponsive, then the

vehicle will attempt a progressive stop which can be overridden by the driver at any time. A driver who

refuses to stop is treated in the same way as existing drivers who fail to stop. Provided a reliable means to

initiate a stop request is provided with full coverage on roads where the feature is to be used, then the

needs of all stakeholder should be met by following this approach.

The Highway Pilot Intervention module is shown in Figure 14:


v1.2


Figure 14 : Highway Pilot GSN – Intervention Module (HP6)

Handle authorised

person stop procedures

G6.2 - Stop Procedures

Always be able to stop in

sufficient time/distance in

case of an emergency

G6.5 - Always Stop in Time

V2V/V2I Solution

S6.9 - Direct CommsAuthorised vehicle flashing light (middle-lane)

manouvere to force slow down to a halt.

S6.8 - Machine Perception of Stop Manouvre

Machine readable 'POLICE STOP'

sign displayed in vehicle or on VMS

S6.7 - Machine Vision of Stop Sign

Reduce speed and move

to nearside lane, then offer

a handover and warn the

driver that a 'pull over' has

been requested. If after a

timeout there is no

handover, then come to a

safe halt

S6.12 - Stop Proceedure

Rely upon driver to notice

conventional means and take

over and stop the vehicle

S6.11 - Driver Override to Stop

Distinction between plural stop

(road closure) and singular ego

vehicle stop

S6.1 - Pull-over or Road Closure

Stop types are detectably distinct

G6.4 - Stop Types are Detectable

Stop from in front in plural case

S6.4 - Front Stop to Close Road

Stop from behind in ego

vehicle case

S6.5 - Rear Stop to Pull-over

Spoofing of authorised person

is not a threat to personal

safety

G6.6 - Spoofing is not a Threat

The driver can override any

automated actions if there

are security concerns as

to the legitimacy of the

stop attempt

S6.6 - Driver Override

Authorised persons will be able to stop the

ego vehicle in a reasonably timely, safe and

consistent manner

G6.7 - Reasonable Safe External Stoppage

Machine recognition of flashing lights

and persistent following

S6.10 - Machine Situation Recognition

A robust stop procedure is

in place whilst false triggers

are minimised

G6.9 - Ego Stop Proceedure

A

Conformant behaviour

across all vehicle

products and

Police/DVSA aware of

intrinsic behaviours

A6.1 - Conformant Stops

The ego vehicle can be notified

to stop under all plausible

conditions via a wireless

communication system

commanded only by authorised

persons

G6.9 - Always Notifiable to Stop

Ego vehicle can be

stopped under all

conditions

G6.8 - Always Stoppable

Proving ground tests of

stop procedures

Sn6.1 - Track Stop Tests

The driver takes full

responsibility for being able

to notice 'pull over' requests

and their fitness to be at the

wheel (not asleep)

G6.10 - Driver is ResponsibleThe feature presents a new

opportunity for the vehicle to

continue on with an

incapacitated driver,

otherwise the responibility is

the same as the manually

driven case

C6.4 - Runaway Vehicle Risk

Runaway vehicles can be

brought to a halt using a

rolling road block

S6.13 - Rolling Road Blocks

Vehicle can be safely

stopped in the event of

driver incapacitation

G6.12 - Runaway Stoppable

Proving ground tests runaway

vehicle stops

Sn6.4 - Runaway Stop Track Tests

Driver retains the option of

control at all times, but the

vehicle can be brought to a halt

safely if the driver fails to

respond by taking positive

control of the vehicle

G6.11 - Driver Control Retained

A remote kill-switch

immobiliser is avoided

due to potential dangers

and infringement of civil

liberties

C6.3 - No Kill Switch

On-road tests of

communications link

and coverage

Sn6.2 - Comms Tests

Generally a stop in-lane

and await further

instructions

C6.1 - Stop In-laneIn general a 'pull over' to

road side or emergency

lane and wait for

authorised person to

approach vehicle

C6.2 - Police Stop

Proving ground tests of vehicle stop

attempts using a suitable persistant

following vehicle

Sn6.3 - Stop Procedure Track Tests

Handle intervention

needed

G6.1 - Intervention

Handle temporary and dynamic

reduction in speed limits

G6.3 - Changes to Speed Limits

V2I Speed limits changes

are aligned to within V2I

beacon range. Must pass

a beacon in reasonable

time before speed limit

changes

S6.2 - V2I Beacons

Traffic sign recognition

S6.3 - TSR

This covers when a

vehicle needs to be

stopped or slowed down

by an external actor such

as the Police or DVSA

C6.0 - Intervention

The individual vehicle

may need to be stopped,

or it may need to stop

with the rest of the traffic

as part of a road closure

C6.1

An incident may create

the need for an

immediate change to the

speed limit

C6.2

Traffic sign recognition of

dynamic changes to the

spedd limit are unlikely to

be reliable enough given

the potential safety

implications surrounding

the need to change the

speed limit (approaching

an incident)

C6.4 - TSR Limitations

Undeveloped here, but

can follow the format of

changes for temporary

lane closures and road

works

C6.3 - V2I Beacons

Key

G – Goal

C – Context

A – Assumption

J – Justification


Sn – Solution

Undeveloped



v1.2


5.9 Operational Envelope (HP7)

The operational envelope refers to the spatial (geographic) envelope and does not extend to cover all

operating conditions which are covered by other modules (such as adverse weather). The vehicle must

handle anything which can reasonably occur within an operating area which it has been designed for.

As with other modules, there is the high-level choice between relying upon the driver to only use the

feature where it is appropriate to do so or using a systematic approach (in effect some form of geo-

fencing15). If geo-fencing is required, then it must be relied upon in proportion with the potential risks

involved if the vehicle was to leave the intended highway and find its own way onto minor or unapproved

roads. An example of this might be if the feature was to be used on a section of unsuitable dual carriageway

for which it may appear to function correctly to the user until a junction or other limiting factor is

encountered with potentially disastrous consequences.

When the journey route meets a natural boundary such as needing to leave on a junction slip road (off

ramp) or the end of a motorway then thought needs to be given to what will happen at that point. The

natural course of action will be to offer to hand over to the driver (either rolling or stationary), but more

thought needs to be given to when the handover is not accepted. If the vehicle simply stops at a threshold

(roundabout give way line at the bottom of a slip road, or signalled junction at the end of a motorway)

then this can present its own danger. The vehicle could continue past the junction until the end of the

motorway is reached or the vehicle runs out of fuel, but this defers the problem rather than solves it. Using

safe harbours is another approach, but it may not be feasible to add safe harbours everywhere where they

might be needed.

The Highway Pilot Operational Envelope module is shown in Figure 15:

15 A geo-fence is a virtual perimeter for a real-world geographic area.


v1.2


Figure 15 : Highway Pilot GSN – Operational Envelope Module (HP7)

Handle operation within an

intended spacial envelope

G7.1 - Operational Envelope

Provide a handover mechanism for

highway exit and exceptional

circumstances

G7.2 - Provide a Handover Mechanism

Drive autonomously without the need

for immediate intervention or

handover whilst on defined highway

routes

G7.3 - No Driving Intervention NeededHandovers should be

requested by the driver, or

offered by the system in

good time with routine

fallback to a safe condition

strategy in place

C7.1 - No Forced Handovers

Handovers are offered/provided in good

time

G7.4 - Sufficient Handover Notice Time

Provide a fallback mechanism

when handover is not requested,

or accepted when offered

G7.5 - Handover Failsafe Fallback

Continue to end of road or leave at

junction/exit and stop at first encountered

intersection

S7.6 - Continue Until Stop Point Reached

Ensure there is a defined reachable

stop point for all defined routes

G7.9 - Stop Points Always Reachable

Constrain operation to

defined routes

G7.6 - Route Containment

Place responsibility on the driver

to not misuse the feature (on

unsuitable routes such as those

with two-way traffic)

S7.3 - Manual Zone Enforcement

Implement an assured localisation

system

S7.4 - Systematic Zone Enforcement

Route study -

certification

needed?

Sn7.1 - Route Study

Education and governance over misuse

are adequate means to ensure the

feature is only used where it is intended

G7.7 - Drivers Only Use Intended Routes

Driver behavioural

studies

Sn7.2 - Driver Studies

System cannot operate

outside defined regions and

will disengage with a safe

stop and wait or 'circle

around' strategy

G7.8 - Geo-fenced Operation

Implement contrained

operating regions using

assured GNSS (EGNOS)

S7.8 - GNSS Geo-fencingProvide a failsafe V2X

localisation beacon to

warn of impending

boundaries

S7.7 - V2X Geo-fencing

Allocated regions cannot be

inadvertantely breached

G7.10 - Geo-fencing Always Works

Safe by design solution,

design, safety case and

supporting

tests/evidence

Sn7.3 - Design and Tests

Road tests of

attempted

breaches of all

regions

Sn7.4 - Road Tests

A

Handovers are only normally required when

leaving operating regions

A7.1 - Handovers Only at End of Defined Routes

Navigation system -

predefined routes or

continue on until end of

allowed road/region

S7.1 - Predefined Routing

Provide 'press for next exit' or

complete manual handover

intervention

S7.2 - Next Exit Requestable

Always provide safe

habours (and hard

shoulder availibilty?)

S7.5 - Safe Habours

No all-lane running so

that there is always a

place to stop?

C7.2 - No all-lane Running

Design limitations mean

that the feature can only be

used safely and effectively

on certain highway routes

such as motorways and

certain supported dual

carriageways as per the top

level feature context. To

ensure safety, there needs

to be some route

containment either

systematically or manually

enforced with supporting

procedures

C7.0 - Operational Envelope

Key

G – Goal

C – Context

A – Assumption

J – Justification



Sn – Solution

Undeveloped



v1.2


5.10 Obstructions (HP8)

For a feature with the remit of Highway Pilot, obstructions on the road are probably the greatest challenge.

Motorways are the most regulated of roads, having exclusions for pedestrians, cyclists, horse riders and

slow moving vehicles. This provides for a more controlled environment to operate the feature within.

However, the difficulty emerges when considering breaches to these regulations and other anomalies such

as goods vehicles shedding their loads or objects falling from bridges over the carriageway. Human drivers

are not impervious to the effects of these rare events, but they do have the benefit of perception and

recognition of unusual situations as they emerge. These situations are of low probability but high

consequence and need to be addressed so that they are handled as well or better than a human driver

(which in itself needs further definition) or they are prevented from occurring when it is known that the

system will not be able to respond appropriately to them. Prevention measures (such as fencing and

monitoring) will still leave a residual risk, but this risk can be set low enough to be palatable to society.

The approach taken has been to divide the argument into static and dynamic obstructions. Objects falling

from a lorry are initially dynamic obstacles but once they come to rest will transition into a set of static

obstructions, which in time could be handled by remotely closing the affected lanes. It is the interim

response period between the load leaving the lorry and the potential for impending collisions that needs

to be addressed. Vehicles can be prevented from driving into objects by directly sensing the obstruction.

We cannot rely upon any classification of the object since it is possible for almost any object to end up in

the road. Generally, it could be argued that static obstructions would be physically connected with the

ground plane (road) so that anything which is touching the road which should not be there is a threat.

However, the logic starts to fall down when considering items such as plastic carrier bags which may or

may not be on the ground and may or may not be stationary.

For low density objects (e.g. plastic carrier bags and soft packaging) it is not normally sensible to brake

abruptly or at all. Sudden braking for phantom objects is in its self a collision risk and may unreasonably

disrupt normal traffic flow. A measure of density is needed to detect these low risk objects in the absence

of human contextual understanding. A sensor which can measure object density of a wide variety of

materials in front of a moving vehicle is not currently feasible. With object classification using image

recognition techniques, receiver operating characteristics come into play, particularly when trying to

decide if any random object presented in the path of a vehicle is something to brake for or not. For some

situations, the risk of false braking events may be viewed as being too high, whilst for others not braking

when needed is equally serious and it may not be possible to satisfy both conditions at the same time. This

is where preventative action is preferred. If many classes of objects can be eliminated by monitoring and

governance, the remaining less plausible occurrences could be more easily met by a conservative braking

strategy i.e if in doubt then brake. As market penetration increases for AVs then the risks from braking

should reduce as result of improved reaction times and advanced warning with back propagation of a

vehicle braking far ahead.

Dynamic obstacles represent even more of a challenge, particularly in the case of livestock or animals in

general. The fact that they are moving implies they have a trajectory and hence this needs to be known

and predicted in order to avoid a collision. This maybe intuitive for a human, but is challenging for

systematic prediction since it first involves classifying the object and understanding what it is, then

deciding what action may be needed. The combination of rarity, with the difficulty in classification and


v1.2


prediction at enough distance to take precautionary action means that there is a reasonable chance that

any measures developed will not work as intended at the point in time when they are needed. This could

be accepted as another risk of automation that must be accepted, but a study should be performed to

check that the actual likelihood of occurrence is sufficiently low and that the reaction of the system is

known and deterministic as far as possible so that a potentially dangerous situation does not translate into

tragedy.

Overall whilst such events as collapsed bridges and sink holes are extremely rare, they will be perceived as being obvious to a human driver and so the automation system should not plough into a rare or unusual but avoidable hazard due to sensing or perception limitations that could have been avoided if a human had been driving. The Highway Pilot Obstructions module is shown in Figure 16:


v1.2


Figure 16 : Highway Pilot GSN – Obstructions Module (HP8)

Handle dynamic obstructions

G8.2 - Dynamic Obstructions

Avoid collision with dynamic

obstruction when it is beyond

the nominal minimum

stopping distance

G8.15 - Avoid When Possible

Avoid or mitigate collisions by

deceleration and braking

S8.3 - Deceleration and Braking

A

Nominal stopping distances are

known for all conditions of operation.

May involve real-time estimation of

surface mue which is known to be

challenging

A8.5 - Known Stopping Performance

Mitigate collisions with dynamic

obstructions that are within the

minimum stopping distance

G8.16 - Mitigate When Unavoidable

A

Dynamic obstacle collision

risks are understood from

studies and road trials and

further analysis

A8.1 - Context Understood

Strategise over vehicle

speed regulation and

positioning etiquette in

relation to other vehicles

S3 - Positioning and Control

A

The current context is always

measureable and understood by the

software

A8.2 - Current Context Always Known

Ensure the risk of a collision

with obstacles is reduced to

ALARP for the current context

whilst making reasonable

progress

G8.4 - Minimise Collision Risk

Apply brakes to reduce

impact severity

S8.10 - Brake to Mitigate

Mitigation performance meets an acceptable

outcome against a performance metric (such

as typical human performance under the

same conditions)

G8.25 - Mitigation Performance is Acceptable

A

Impact severity is known,

understood and sufficiently

predictable for all intended

operating conditions

A8.8 - Known Impact Severity

Handle static obstructions

G8.3 - Static Obstructions

Test of nominal stopping

distances and reaction

performance

Sn8.2 - Stopping Performance

Crash test impact

analysis

Sn8.3 - Crash Tests

Every credible collision risk for the intended area

of operation has been identified and can be

sensed and detected under all conditions of

operation

G8.23 - All Collision Risks Known and Identifiable

Sensing and

enviromental tests

Sn8.1 - Sensing Tests

Should understand lane

disipline

G8.10 - Lane Disipline

All driver behaviours have been

identified and understood and

suitable heuristics can be applied

G8.13 - All Behaviours are Known

Study of driving

behaviours

including those in

response to AVs on

the road

Sn8.9 - Driver StudyOn-road trials to

demonstrate the

effectiveness of

heuristics an correct

lane disipline is

maintained

Sn8.8 - Road Trials

Limit occurance of

incursions on to the

carriageway to ALARP

G8.9 - Limit Occurance

Restrict access to

carriageway

S8.7 - Restrict Access

Collision risks from animals or unauthorised persons

'roaming' the carriageway are reduced to an acceptable

level

G8.22 - Risk of Collision with Roamers Acceptably Low

Use governance or raise awareness

to risks as a deterant

S8.13 - Governance and AwarenessFencing and other

physical or active

measures

(monitoring/policing)

S8.14 - Barriers

Access restriction measures are

adequate to reduce carriageway

incursions to an acceptable level

of target incursions per year

G8.28 - Target Incursion Rate Met

Study of current incidents

and risks

Sn8.6 - Current Risk Study

Trial period used to

show incursion rate

reduced to meet or

exceed target value

(prior to roll-out of

feature)

Sn8.7 - Trial Period

Active road monitoring (via

CCTV and/or patrols) and

clean-up crews

S8.5 - Remote Monitoring

Incident response and cleanup time is fast

enough to reduce collisions risks to an

acceptable level

G8.18 - Sufficient Incident Repsonse Time

Provide a range of sensing

that can be fused to measure

and detect the size and

position of all credible

obstacles under all intended


S8.12 - Robust Fused Sensing

Control action can reduce risk to ego

vehicle to ALARP

G8.12 - Control Action Reduces Risks

Minimise exposure to

foreign objects to ALARP

G8.11 - Minimise Exposure

Handle manifestations of

obstacles

G8.8 - Obstacle Manifestations

Brake and/or steer to avoid or mitigate

collision severity

S8.6 - Brake and Steer to Avoid or Mitigate

All obstacles that pose a collision risk are measurable

and detectable under all intended operating conditions

G8.20 - Collision Risks are Measurable and Detectable

Only obstacles which pose a credible

collision hazard are acted upon

G8.21 - React to Collision Hazards Only

False positive obstacle

detections are avoided or

minimised to an accepable level

G8.24 - Minimise False Positives

Optimal Receiver operating

characteristic (ROCs) and sensor

fusion tradeoffs are achievable for

required detection performance

G8.27 - Sensing Tradeoff Performance

Real-world test

library from on-road

trials taken under

all intended road

conditions

Sn8.5 - Test Library

Risks arising from potential collisions with

foriegn objects are minimised by resulting

control behaviour of the ego vehicle

G8.19 - Control Action Minimises Collision Risks

Research and implement

optimal control strategies based

upon measured and

observation based heuristics

S8.11 - Control Reactions Study

Simulation study of

collision scenarios and

optimal reactions

C8.1 - Simulation Study

Target reaction performances

are met (greather than or equal

to acceptable human

performance)

G8.26 - Target Performance Met

Controlled condition proving

ground tests of credible scenarios

Sn8.4 - Test Track Scenario Tests

Handle foriegn objects

on and falling to the

carriageway

G8.7 - Foriegn Objects

Avoid or reduce risk of

collisions with other road

vehicles

G8.5 - Avoid Other Vehicles

Reduce collision risk by

use of V2V reporting and

V2I beacons

S8.2 - Comms Reporting

Feed-forward local-dynamic-map

information can reduce the likelihood

of primary and secondary collisions

G8.6 - LDM Propagation Reduced Risk

Reduce speed/avoid lane in the

vacinity of a reported foreign object

obstruction

S70 - Speed Reduction and Avoidance

The proposed measure is

effective at avoiding

collisions or reducing

hazards from collision to an

acceptable target level

G8.14 - Measure is Effective

Tests which show

system reaction

performance at and

around the

predetermined safe

to proceed speed

Sn8.10 - Track Tests

A

This includes all normal and

plausible abnormal

behaviours such as wrong-

way driving

A8.4 - All Behaviours Covered

Handle static obstructions

as per foriegn obstacles

method

S8.1 - Static Obstructions

Handle Obstructions

G8.1 - Obstructions

A

Swerving becomes a

better method of

avoidance as a

function of increasing

speed. However, this

can lead to far more

complicated scenarios

emerging which could

result in higher levels

of risk with many

design and tests

vectors to prove

A8.3 - Swerving

The detection error tradeoff

(DET), false negative rate

(missed detections) vs. the

false positive rate (false

alarms) ultimetely determines

the difference between action

and inaction both of which can

result in serious

consequences if chosen

incorrectly

C8.2 - Detection Error Tradeoff

Reaction performance study

to determine safe speed to

proceed into a suspect zone

Sn8.11 - Performance StudyTake measures to prevent

objects being thrown on to

the carriageway (e.g. from

footbridges)

S8.4 - Prevention

Prevention measures are

effective commensurate with

the risk and resulting

frequency of occurance

G8.17 - Prevention is Effective

J

Object mass and

density is a strong

factor in deciding if an

avoidance action is

more dangerous than

just hitting the object. A

human driver may be

able to recognise the

object from its form

and make a near

instantaneous

judgement. This will

remain a challenge for

automated systems

due to sensing

lmitations and a lack of

contextual awareness,

therefore prevention is

the best cure

J8.1 - Object Density

Obstructions are things

that get in the way of the

normal and legitimate

path of the vehicle which

present a danger to the

vehicle, its occupants,

and in the case of living

obstructions,

themselves. Obstructions

can start out as dynamic

(moving or liable to

move) and may later

become static in the case

of falling objects

C8.0 - Obstructions

Key

G – Goal

C – Context

A – Assumption

J – Justification


Sn – Solution

Undeveloped


GSN Discussion of Outputs – ‘Urban Pilot’ Use Case

v1.2


6 GSN Discussion of Outputs – ‘Urban Pilot’ Use Case

6.1 Introduction

This section presents the results of the GSN for the ‘Urban Pilot’ use case.

6.2 Overview

The Urban Pilot use case is considered as an M1 vehicle with the modification that it has no provision to

be manually driven, and therefore handover to a human driver within the vehicle is not an option. The

vehicle is to be operated in designated urban zones up to 30 mph either as part of a managed fleet or by

individual owners. The significant difference over Highway Pilot, other than the removal of manual

controls, is the ability to run without occupants. Despite being slower, urban environments are inherently

more chaotic and feature two-way traffic with a much broader mix of road user types. This places

considerable additional complexity on the Urban Pilot compared to the Highway Pilot. Much of urban road

travel requires ad-hoc arbitration between individual drivers in addition to the need to negotiate junctions

and crossings of various types. By its nature this represents a significant challenge to automate to a level

which requires no direct supervision. True autonomy for such a vehicle is difficult to define never mind to

realise and as such what inevitably must be considered is a higher level of automation with some accepted

limitations. These limitations can be met by a variety of means, from a simplification of the environment

using new rules of the road (e.g.no jaywalking), an acceptance of new types of accidents (possibly traded

against a reduction of inattentive driver related accidents), through to supporting infrastructure to widen

the perception of the vehicle beyond what is possible for it to sense from its own location and sensor field

of view.

Human ‘common sense’ hazard anticipation, preconception or perception can to some extent be emulated

by emerging A.I. techniques (such as off-line trained CNNs), but we should be realistic as to what can be

achieved with these A.I. techniques and not allow them to result in automation bias. In general, we advise

that they should only be used where they can only add benefit and their failure does not significantly

worsen a situation, such as triggering unnecessary emergency braking or other evasive action which in

itself could be hazardous.

Some modules from the Highway Pilot GSN are considered broadly applicable to the Urban Pilot use case,

and have not been altered. These include:


v1.2



HP1 Lane Reallocations This covers lane closures (e.g. due to a stranded broken down vehicle)

and changes in lane usage restrictions (bus lanes, car share lanes)

HP3 Lane Rerouting This is for when a lane position needs to be temporarily or

permanently changed, usually during and after roadworks

HP4 Adverse Weather Strategies to restrict the use of the feature during bad weather,

particularly during the sudden onset of challenging weather when the

system is already active

HP5 Mechanical Failure To make sure that mechanical failures do no go undetected while the

feature is in use.

HP8 Obstructions Strategies for handling collisions with static and dynamic obstructions

in the road

Table 5 : Modules from Highway Pilot Use Case which are considered applicable to Urban Pilot Use Case

For the ‘Obstructions’ module (HP8), there may be differences in strategy associated with the differences

in design speed, but the issues are largely the same. Passive containment measures (such as fencing and

monitoring) are probably impractical in the urban environment and more reliance on systematic vehicle-

based measures may be appropriate (i.e. sense obstruction and stop). Pedestrians in the road are handled

in separate modules for Urban Pilot.

The following table outlines new modules that were constructed as part of the Urban Pilot GSN.


UP2 Road Etiquette This covers allowing emergency vehicles to pass and appropriate speed

regulation. Also pick-up/drop-off and emergency stopping, traffic

merging and prudence when passing pedestrians on pavements

UP7 Operational Envelope Ensuring the feature is only active on the roads it is intended for. It

does not cover other aspects of the control envelope such as stability

and speed regulation

UP9 Junctions and

Crossings

Handling of signal and priority controlled junctions and level crossings

UP10 Pedestrian Crossings Handle Zebra, signalled and uncontrolled pedestrian crossings

UP11 Overtaking Handle being overtaken (overtakee), facing an on-coming overtaker,

overtaking and undertaking

UP12 Antisocial Behaviour Resilience to mistreatment and misuse of the vehicle such as pranks,

use of the vehicle for criminal activity, entrapment of vehicle

occupants, and general poor treatment from other road users

Table 6 : Urban Pilot Use Case GSN Modules

The structure of the Urban Pilot GSN is confirmed as shown in Figure 17:


v1.2


Figure 17 : Urban Pilot GSN – Top Level Structure

Drive along designated

'urban' sections of road

which are classified at up

to 30mph, autonomously,

safely, and obeying the

rules of the road without

the need for human

occupancy.

G0.1 - Provide Service

Equivalent to a current M1

vehicle but without the

provision to be manually

driven under normal


C0.1 - Vehicle

Provision for complete

fully automated journeys

with or without occupants

to be completed within

designated urban zones.

The zones will consist of

roads of no more than

30mph speed limit

designation. Vehicles

may be operated as a

managed fleet or owned

by individuals

C0.2 - Feature Context

All classes of operating

issues have been

identified and sufficiently

mitigated

G0.2 - Identify All Issues

Taxonomy of issues

exercise performed

C0.3 - Issue Taxonomy

J

By identifing all

classes of issues,

assurance is provided

that any given

plausibile issue will be

covered and handled

in a predetermined

way

J0.1 - Potential Issues

A

Studies and road trials are

suffient coverage to reveal

all types of credible issue

A0.1 - Road Trial Coverage

Handle sudden onset

mechanical failures

UP5 - mech_failure

Handle spatial operation

envelope

UP7 - op_envel

Handle intervention

needed

UP6 - intervention


conditions

UP4 - adverse_weather


issues

UP2 - road_etiquette

Handle lane Re-rounting

UP3 - lane_rerounting

Handle lane

reallocations

UP1- lane_reallocations

On-road supervised trials

performed to identify real-

world issues

Sn0.1 - Trials For Issues

Handle Obstructions

UP8 - obstructions

Junction and Crossing

arbitration

UP9 - juncitons_crossings

UP10 - pedestrian_crossings

UP11 - overtaking

UP12 - antisocial_behaviour

Key

G – Goal

C – Context

A – Assumption

J - Justification

UP – Urban Pilot

Module

Green = unchanged

from Highway Pilot

Red = Unchanged,

with caveats

mentioned in report

Amber = New Urban

Pilot Module

Sn – Solution



terminology


v1.2


Details of each module that is unique to the Urban Driving use case are provided as follows.

6.3 Road Etiquette (UP2)

In addition to emergency vehicle passage and speed regulation covered in the Highway Pilot road

etiquette, this module includes coverage of passing parked vehicles, passing pedestrians, appropriate

stopping, and merging obstruction etiquette which will be explained in the sections below.

The road etiquette modules have been broken down further to sub-modules, as shown in Figure 18:


v1.2


Figure 18 : Urban Pilot GSN – Road Etiquette Module Structure


issues

G2.1 - Road Etiquette

Road etiquette covers the

many unwritten and

unspoken informally

implied rules of the road

such as offering and

reinquishing right of way

and proportionate

modulation of vehicle

speed to the prevailing

conditions and perceived

surrounding risks. The

coverage here is far from

exhaustive and requires

further expansion for

completeness. Urban

driving covers a wider

range of potential

etiquette issues than

highway driving

C2.0 - Road Etiquette

UP2.1 - Passing Parked Vehicles UP2.2 - Passing Pedestrians UP2.3 - Appropriate Stopping UP2.4 - Emergency Vehicle Passage UP2.5 - Speed Regulation UP2.6 - Merging Obstruction Etiquette

Key

G – Goal

C – Context

UP – Urban Pilot Module

Green = unchanged from Highway Pilot

Refer to Section 4 for further explanation of

terminology


v1.2


6.3.1 Passing Parked Vehicles (UP2.1)

Parked vehicles present a risk due to the potential for doors to be opened as well as obscuring pedestrians

who may be attempting to cross between parked vehicles. Human drivers may be much better at detecting

the signs (visual cues) that a vehicle occupant is present and may be about to open their door. It is probably

unrealistic to expect machine vision and perception to be able to see inside each car and make a judgment

whether there is a risk someone is about to try to leave their car. The mitigation options range from doing

nothing and accepting the risks, through to slowing down and/or increasing the clearance by moving across

the lane if space allows.

The Passing Parked Vehicles sub-module is shown in Figure 19.

Figure 19 : Urban Pilot GSN – Passing Parked Vehicle sub-module (UP2.1)

Manage risks associated with

passing parked vehicles

G2.1.1 - Passing Parked Vehicles

Leave additional lateral

clearance where available

S2.1.1 - Increase Clearance

Parked vehicles present a risk

due to the potential for doors

to be opened and also

obscuring pedestrians who

may be attempting to cross

between parked vehicles.

Human drivers may be much

better at detecting the signs

(visual cues) that a vehicle

occupant is present and may

be about to open their door

C2.1.1 - Parked Vehicles Risk

Reduce passing speed to

give more observation

time (avoidance) and

reduce collision speed

(mitigation)

S2.1.2 - Reduce Speed

The incident rate is reduced or

not increase by the introduction

of AVs passing parked cars

G2.1.2 - Measures are Effective

Initial trials to eliminate any

unintended consequences.

Monitor behaviour and accident

reports thereafter

Sn2.1.1 - Trials and Monitoring

Do nothing additional

S2.1.3 - Do NothingDay time running lights

passively help to reduce

poor observational risks

C2.2.2 - DRL Risk Reduction

Key

G – Goal

C – Context

S – Strategy (yellow = singular, blue =

one of several options)

Sn – Solution

Refer to Section 4 for further explanation

of terminology


v1.2


6.3.2 Passing Pedestrians (UP2.2)

Detecting pedestrians in the road is covered by obstructions and pedestrian crossings modules. However,

one issue of etiquette is anticipating when pedestrians who are not waiting to cross may suddenly step on

the road either deliberately or unintentionally. Pedestrians can present a risk if they enter the carriageway

at short notice and a pre-emptive action may need to be taken. Examples might include an unaccompanied

young child, a person under the influence of alcohol or a crowd of rowdy teenagers waiting for a school

bus on a narrow footway. One option is to do nothing anticipatory. Real-world incidents usually result from

a combination of events aligning in an unfortunate way. Automation will not suffer from human driving

deficiencies such as driver inattention and breaking of speed limits so even if no direct action is taken there

may be sufficient net reduction and mitigation of many pedestrian step-out related collisions. The

disadvantage of automation is that an attentive human driver may be able to spot pedestrians who

represent a risk of entering the road and apply due diligence by slowing down, moving the vehicle further

away from the kerb, or sounding the horn. This is one occasion where A.I techniques may prove beneficial

since they have ability to evolve an expert judgement to detect risk cases and the consequences of false

positive detections are minimised (e.g. unnecessary slowing down and moving out, pre-charging the

brakes and emergency stop etc).

The Passing Pedestrians sub-module is shown in Figure 20.


v1.2


Figure 20 : Urban Pilot GSN – Passing Pedestrians sub-module (UP2.2)

Manage risks associated

with passing pedestrians

on footways

G2.2.1 - Passing Peds

Do nothing additional that

is predictive, and behave

appropriately when

pedestrians enter the

carriageway

S2.2.1 - Do Nothing

Slow down/move out (if

there is sufficient space)

S2.2.2 - Adjust Motion

Can detect pedestrians

candidates who present an

increased risk of entering the

road

G2.2.3 - Detect Suspect Peds

Some people may

present a risk of entering

the carriageway at short

notice and pre-emptive

action may need to be

taken. For instance, a

young child not with a

parent, or a person under

the influence of drink or

drugs, groups of

teenagers showing off

whilst not paying

attention to the road

C2.2.1 - At Risk Peds

There is a risk that learned

heuristics become exploited

for amusement or other

reasons if they are observable

and can be used to induce

reactions from the vehicle

C2.2.2 - Malicious Exploitation

AI supervised learning of

suitable heuristics (can be

improved with time based

upon real-world

experience)

S2.2.3 - AI Heuristics

A Training library is

created and added to

over time to improve

prediction reliability

Sn2.2.2 - Training library

Step-outs are accurately

predicted without an

unreasonable level of false

predictions occuring

G2.2.4 - Good Prediction Rates

Tests (mainly for avoidance of

false positives, rather than

stooges performing step-outs)

and monitoring for continuous

improvement

Sn2.2.3 - Tests and Monitoring

There are not unintended

consequences of learned behaviours

G2.2.5 - No Unintended Consequences

Pedestrian collisions with AVs do not

exceed those of manually driven

vehicles

G2.2.2 - No Increase in Ped Collisions

Monitor accident

statistics and collision

reports

Sn2.2.1 - Monitor Stats

Key

G – Goal

C – Context

S – Strategy (yellow = singular, blue =

one of several options)

Sn – Solution

Refer to Section 4 for further

explanation of terminology


v1.2


6.3.3 Appropriate Stopping (UP2.3)

Appropriate stopping considers how and where to appropriately permit the vehicle to pick-up and set

down passengers, as well as the provision for an occupant initiated emergency stop (E-Stop). Much of this

is procedural and could be resolved as part of a system deployment and it could be for the vehicle

manufacture themselves to address the needs and preferences of their users. However, some

consideration needs to be given to the fact that automated stopping for egress and ingress may lack the

finesse and diligence that a human driver may use, and just following the Highway Code as it stands may

not be sufficient in practice. Consideration of an E-Stop should be given for unforeseen and even foreseen

circumstances which cannot be gracefully handled in any other way. The strategy presented in the GSN

model only offers a controlled deceleration and not a full braking force stop or complete power-down of

the system. Either of these two latter cases could themselves be dangerous in use. The counter risk is that

a progressive E-Stop might misused, and passengers could start to use it only for the purposes of stopping

to alight prior to the preprogramed destination of the vehicle.

It might be worth considering having a kill-power switch (similar to those fitted to busses) on the outside

of the vehicle which can only be activated when the vehicle is stationary. The reverse argument to this is

that it would also present a significant security risk (for example if someone wanted to disable the vehicle

to mug the vehicle occupants) and existing passenger vehicles do not generally have this albeit that they

are currently unable to run-empty.

The Appropriate Stopping sub-module is shown in Figure 21.


v1.2


Figure 21 : Urban Pilot GSN – Appropriate Stopping sub-module (UP2.3)

For pick-up/drop-off purposes

as well as emergencies

G2.3.1 - Appropriate Stopping

G2.3.2 - Allow Passengers to Alight G2.3.3 - Allow passengers to Board

Occupant initiated

emergency stop for

whatever legitimate

reason

G2.3.4 - E-STOP

Create dedicated pick-up/drop-off

zones to discourage potentially

more traffic flow distruptive ad-hoc

stopping

S2.3.1 - Pick-up and Drop-off Zones

Ad-hoc stopping: As per

highway code with

refinements if required

S2.3.2 - Ad-hoc Stopping

A rate less than full braking, but

an immediate response with a

proportionate stop

S2.3.3 - Controlled Deceleration

There are no behavioural

issues created by AVs

stopping and no

unintended

consequences

G2.3.5 - No Issues

If no issues are detected

during an initial roll-out phase

then continue to monitor for

issues and correct stopping

strategies as required

Sn2.3.1 - Trials and Monitoring

Key

G – Goal

S – Strategy

Sn – Solution




v1.2


6.3.4 Merging Obstruction (UP2.6)

At time of peak traffic volumes and in slow moving queues, often the absolute right of way is relinquished

to allow others to merge in the interests of common sense and to keep the traffic moving or just due to

empathy in the hope that others will do the same for you. There are no rules for this (except for certain

cases, such as allowing busses to pull out), and some rules may need to be developed if AVs are to follow

the example of their human driven counterparts. Doing nothing might be an option particularly while CAVs

have a low market penetration and make up only a small fraction of the UK parc. This would also allow

time to wait for managed connected infrastructure to emerge which may intelligently control traffic flow

at pressure points for example, rather than attempting to solve the problem from the outset. Otherwise a

strategy of leaving gaps or a merge in turn approach could be taken. Whatever approach is taken, it should

be monitored for undesirable effects that may worsen traffic congestion or driver frustration, rather than

improve it.

The Merging Obstruction sub-module is shown in Figure 22.

Figure 22 : Urban Pilot GSN – Merging Obstructions sub-module (UP2.6)

Don't obstruct side roads or

roundabout entries in slow moving and

queing traffic so that others can make

progress at peak times

G2.6.1 - Merging Obstruction Etiquette

Employ a 'one in/out at a

time' strategy such that

space for one vehicle to join

from a mergin queue is left

and the space is reduced

after a vehicle has merged

S2.6.1 - One In/Out Strategy

Leave gaps in queues to

allow merging

opportunites for other

vehicles

S2.6.2 - Leave Gaps

This describes situations

such as letting someone

out from a sideroad to

join a queue where they

may be left waiting for a

unreasonably prolonged

time, but will not lengthen

the wait in the queue

significantly by letting

them out

C2.6.1 - Scenarios

Do not modify behaviour

S2.6.3 - Do Nothing

Initial penetration of the total parc may

be low enough that apparent

unyielding or discourteous merging

behaviour will not impact heavily on

traffic flow. As AV penetration

increases, there may be a

corresponding reduction in

congestion which may alleviate the

need for an algorithmic strategy

C2.6.2 - Possibililty of a Non-problem

The chosen strategy does not have any

unintended negative consequences

G2.6.2 - No Unintended Consequences

Monitored trials

followed by further in-

use monitoring.

Software updates offer

the opportunity to tune

behaviours for best

results

Sn2.6.1 - Monitoring

Key

G – Goal

C – Context

S – Strategy (yellow = singular, blue = one of

several options)

Sn – Solution


terminology


v1.2


6.4 Operational Envelope (UP7)

This module is largely the same as its counterpart for Highway Pilot. The main difference is that there is no

option to trust a human driver to constrain automated operation to the intended regions and road types.

For this reason, only systematic methods of geo-fencing are considered. The Urban Pilot Operation

Envelope module is shown in Figure 23.

Figure 23 : Urban Pilot GSN – Operational Envelope-module (UP7)

Handle operation within

spacial envelope

G7.1 - Operational Envelope

Drive autonomously without the need

for any direct intervention

G7.2 - No Driving Intervention Needed

Constrain operation to

defined routes

G7.3 - Route Containment

Implement an assured localisation

system

S7.1 - Systematic Zone Enforcement

System cannot operate

outside defined regions

G7.4 - Geo-fenced Operation

Implement contrained

operating regions using

assured GNSS (such as

EGNOS)

S7.4 - GNSS Geo-fencing

Provide a failsafe V2X

localisation beacon to

warn of impending

boundaries

S7.2 - V2X Geo-fencing

Allocated regions for operation

cannot be inadvertantely breached

G7.5 - Geo-fencing Always Works

Safe by design solution,

safety case and

supporting

tests/evidence

Sn7.1 - Design and Tests

Road tests of

attempted

breaches of all

regions

Sn7.2 - Road Tests

Use signage or other

physical means (such as

inductive markers in the

road) to indicate

boundaries of operation

S7.3 - Land Marks/Other

J

The system can be designed to

only plan routes within

authorised regions of operation,

however it then creates the need

to always know the current

location so as to not be

inadvertently lead out of the

intended operational zone, and

places safety requirements on

the route data and planning, or

the definition of the safe

operational zone

J7.1 - The Need for Geo-fencing

A

Since the vehicle has

no manual controls

and can run with no

occupants a

systematic approach is

the only option

A7.1 - Systematic Only

Design limitations mean

that the vehicle can only be

operated safely and

effectively on certain routes

that are limited in speed

and complexity that the

vehicle will face. To ensure

safety, there needs to be

some route containment

either systematically or

manually enforced with

supporting procedures

C7.0 - Operational Envelope

Key

G – Goal

C – Context

A – Assumption

J – Justification

S – Strategy (yellow

= singular, blue = one

of several options)

Sn – Solution



terminology


v1.2


6.5 Junctions and Level Crossings (UP9)

The junctions considered for this module have been divided in to:

• signal controlled junctions;

• priority controlled junctions;

• level crossings;

• signalled controlled junctions with a fault failure.

Starting with signalled junctions, the main concern is being able to detect the signal phase both in time to

stop for a red signal and to not pass through a red signal at any time. The means of detection falls into two

categories. The first is to use machine vision (normally Complementary Metal-Oxide Semiconductor

(CMOS) cameras) to see the signal lamps in the same way as human drivers do. The second is to use the

more direct method of Infrastructure to Vehicle (I2V) radio communications.

It is suggested by the authors that whilst it may at first appear to be convenient strategy to use vehicle

mounted cameras to view existing traffic signals, it is conceptually flawed and problematic. Humans are

capable of vision fixation and tracking of a visual target through a variety of means such head and body

movement, as well as saccadic eye motion to give which is known as directed or active vision. The human

eye also has variable aperture and focus so together can cope with resolving the detail from very complex

scenes in challenging light conditions. Beyond this, humans are capable of contextual perception so that

for instance a green balloon held in front of a signal by a pedestrian waiting to cross would not be mistaken

for a green traffic signal16. The windscreen mounted cameras used on vehicles are fixed focus and aperture

and cannot be pointed. This is primarily for keeping cost, complexity and reliability at their optimums, but

adding variable focus, aperture, and a mechanic servo means of directing the camera would tend to add

more than it solves. All of these items take time to actuate and you need to know in advance where to

direct the area of interest to which requires perception. Notwithstanding that these technical challenges

could perhaps be solved with time, it is still an inferior and unnecessarily challenging strategy. The signal

phase is known to the traffic signal controller to a high level of integrity. The notion of converting this to

an analogue optical signal then attempting to convert that back to a digital signal using optical sensing

from a moving vehicle under any possible light condition does not hold up to reason when the outcome of

that process is preventing potentially life threatening collisions.

Various V2I schemes are emerging around the world (e.g. Dedicated Short-Range Communications (DSRC))

to make traffic signal phasing available wirelessly to vehicles. However, this information is being

transmitted as a driver advisory, not as a mission critical piece of information. This exchange of information

needs to be developed to be failsafe. The source of the information is already failsafe but how it is

propagated may not be and further analysis and development may be needed. In addition, the

communication needs to be allowed to fail (be absent when expected) without harmful consequences to

the approaching vehicle. For this to be allowed, the vehicle needs to know when to expect a transmission.

For this to work the vehicle system needs to know where it is against a digital map to realise that it is

approaching a signalled junction and needs to have the real-time signal status for the junction so that it

can stop the vehicle if this information cannot be obtained for whatever reason. This places a high level of

16 http://www.theregister.co.uk/2016/08/24/google_self_driving_car_problems/

http://www.theregister.co.uk/2016/08/24/google_self_driving_car_problems/


v1.2


dependence on digital map integrity and on the performance of localisation. Both must be ‘correct’,

commensurate with the risk of running a red light. This is also true where cameras are used since a missed

signal needs to be noticed in its absence.

Some consideration to signal failure is given also. Currently signalling systems cannot fail in such a way as

they show a green light to two or more conflicting directions. This is covered by TR 2500 and BS EN

12675:2001. Generally multiple red signals are provided to ensure redundancy. If there is a severe fault,

such as two or more red signals failing, all signals are extinguished to avoid ambiguity. Some other

countries use a flash red-amber sequence to indicate a fault. Problems for CAVs may still arise for partial

failures of certain signals. This is another benefit to using a wireless radio V2I approach where rather than

trying to infer a fault, the exact status can be transmitted to vehicles so that they may proceed with

caution.

Priority controlled junctions are another significant challenge for which it is difficult to offer a general

strategy beyond that of proceeding with caution. A move towards wirelessly managed junctions, possibly

signalled junctions would assist with resolving the technical challenge, but may be impractical in practise.

Level crossings are out of scope for the feature, but cannot be simply ignored either. The strategy is to

avoid them by choosing alternate routes or having them removed, but if they are to be avoided then this

needs to be enforced to the same level of integrity as the risk of encountering one and an incident

occurring. If this cannot be guaranteed, then additional monitoring and support at level crossings may be

needed in urban areas where CAVs may encounter them. The Junctions and Level Crossings module is

shown in Figure 24.


v1.2


Figure 24 : Urban Pilot GSN – Junctions and Level Crossings-module (UP9)

Navigate all junction and

crossing types safely and

efficiently

G9.1 - Navigate Junctions

G9.2 - Signal Controlled JunctionsG9.3 - Priority Controlled

Use machine vision and

perception

S9.9 - Perception

Failsafe V2I connection to

signals on approach

S9.10 - Comms

The system must always be aware

of the current signal state before

entering a signalled crossing or

junction

G9.10 - Correct Reading of Signals

Ability to detect lane

margins, select the most

appropriate lane and

handle when other road

users do not follow lane

discipline

G9.5 - Lane Following

Read road markings and post/gantry

mounted signage to understand how to

proceed

S9.4 - Signage and Markings Perception

Use a digital map to

understand the lane

discipline

S9.5 - Digital Map

Digital maps are updated

with changes to static road

layout before use

G9.12 - Maps Kept Current

A

Less critical than highway

case when considering

lane disipline?

A9.3 - Map Data Criticality

Failesafe behaviour if a

signalling fault occurs

G9.4 - Signal Failure

A failed visual signal may not present a

direct issue to the AV if using comms, but

confusion may arise for manual drivers

which should be anticipated

C9.4 - Visual Only Failure Caution Required

Make a decision to

proceed 'on green'

G9.7 - Decision to Proceed

Proceed slowly and rely upon

sensing to detect potential trajectory

conflicts

S9.6 - Ego Vehicle Sensing of SceneAbility/necessity to clear

the junction. Emergency

vehicles. Late

proceeders, red-runners.

Right-turn give-ways.

Pedestrians.

C9.5 - Heuristics

G9.6 - Decision to Proceed

Make sure scene is clear.

C9.2 - Clear to Proceed

A proceed with caution approach

can be used if there is any

degridation of the normal

signalling function (e.g. broken

lamp)

S6 - Comms Notification of Failure

All signal failures are detectable through self-

diagnostics

G9.16 - Signal Failures are Always Detectable

Design and tests of signal

failure modes and

diagnostics

Sn9.1 - Self-dianostic Tests

Fleet management map

update procedures

Sn9.10 - Fleet Map UpdatesLocal authority change notification

procedures

Sn9.12 - Authority Change Nofification

J

Low speed operation limits the risk

of incorrect lane useage such that

this can be managed by procedures

rather than requiring system

interlocks on maps

J9.2 - Low Speed Reduces Reliance

Localisation minimum required

performance is always met

G9.20 - Localisation Performance

Camera technology limitations limit

the approach speed as it can be

too late to stop once a signal has

been sensed or detected as

missed. Also, the risk of false

positive/negative detections may be

unacceptably high against the

ascociated hazards. A further issue

is that signals may not be visible in

standing traffic due to field of view

limitations. A human driver is able

to move around to gain visibility or

use judgement from the

surrounding vehicles as the current

signal phase

C9.6 - Camera and FoV Limitations

Locally stored map data

is always correct and up-

to-date before use

G9.21 - Map integrity

The system must independentely

know when it is approaching a

signalled area

G9.14 - Signal Location Awareness

Use digital mapping and

locaisation to know when a

signalled area will be approached

S9.16 - Mapping and Localisation

Road tests of

localisation system

Sn9.4 - Road Tests

Localisation system

design and test

documentation

Sn9.6 - System Docs

System Design

showing adherence to

recommended

practices such as Data

Safety Guidance (see

SCSC DSIWG

Guidance)

Sn9.7 - System Design

Documentary evidence of end-

to-end map update procedures

showing how data correctness

and integrity is maintained from

source to vehicle

Sn9.9 - Map Update Procedures

Assement of the hazards and

levels of risk resulting from

incorrect map data

Sn9.8 - Mapping Risk Assesment

Assement of the hazards and

levels of risk resulting from

incorrect an localisation

Sn9.5 - Incorrect Loc HAZOP

Up-to-date refers to changes in static

features such as lane allocations and

signal positions which are seldom

changed and only through planned

works

C9.7 - Clarification of Map Timeliness

J

The ego vehicle needs to

know where it is relative to

the approach of an

intersection or crossing.

Reliance upon visual

detection alone is too

weak and could result in a

red signal being crossed

J9.3 - Junction Reckoning

J

For junctions to always be

correctly anticipated, minimum

location performance must

always be met and map

integrity and acuracy

guaranteed to a level

commensurate with the risk of

proceeding through a junction

in an unfettered manner at an

incorrect signalling phase

J9.4 - Reckoning Performance

Harminisation between the

notification of a road change

and a map update and

dissemination of the update

G9.15 - Update Harmonisation

Tests which evidence the worst

consequences of a failed map update

are an acceptable risk against the

likelihood of occurance

Sn9.11 - Map Failure Acceptable Risk

J

Undeveloped since not considered

viable against the risks given that

existing satellite nagivational aid

systems already contain lane allocation

information

J9.1 - Undeveloped Signage Perception

S9.7 - Infrastructure Relayed SensingInfrastructure manages

progression of individual

vehicles through a junction.

S9.8 - Fully Managed Junctions

Visual Indicator Failure

G9.8 - Indicator Failure

Complete Failure (e.g.

power failure at a

junction)

G9.9 - Full Outage

Use a tentantive approach to

allow a slow progression

though the junction

S9.15 - Proceed With Caution

A fall-back failsafe

strategy is in place in the

case of a total junciton

signal failure

G9.13 - Arbitration is Safe

Detection and V2I broadcast to

allow rerouting and diversion

S9.14 - AV Junction Avoidance

Failures can always be detected remotely

and can be reliably reported to AVs

G9.17 - Failures are Remotely Detectable

No chance of a partial failure such

that traffic approaching from a

non-failed approach (phase) are

unaware of any abnormality

G9.19 - No Hidden Partial Failures

Warn functioning

approaches during a

failure

S3 - Warn All Sides Turn off (extinguish) all

signals on any significant

failure to any approach

(phase). Signal the failure

over V2I comms if

implemented

S4 - Power Down

All approaches to a junction or

intersection must be aware of a

signal failure that may cause

unexpected behaviour from

opposing approaches

G9.18 - Mutal Failure Awareness

V2I Comms reporting

system design and tests

Sn9.2 - Comms Reporting

Chosen method(s) are reliable

and effective and the time of

failure and thereafter

G9.22 - Method Mitigates Risks

Simulation, proving ground

user trials, live junction trials

Sn9.3 - Simulation and Trials

G12 - Roundabouts

Covered by TR 2500 and

BS EN 12675:2001.

Generally Red signals

are redundant and a red

failure results in all

signals being

extinguished to avoid

ambiguity. Some other

countries use a flash red-

amber sequence to

indicate a fault

C9.1 - Current Standards

A

Existing signalling systems are

already failsafe with self-

diagnostics and shutdown on fault

so AVs do not need to detect fault

unplausible conditions such as a

green signal being shown

siumtaneously on opposing

phases

A9.1 - Existing Signals are Failsafe

Will never obstruct a train

without priority

G3 - Level Crossing Junctions

Remove all level

crossings in areas where

the ego vehicle will

operate

S9.2 - RemovalUse other routes and

gaurantee that a level

crossing can never be

entered in error (due to

being lost or confused)

S9.1 - Avoidance

Provide an independent

failsafe mechanism e.g.

physical barriers coupled

with full-time human

operators, or automated

monitoring system

S9.3 - Make Failsafe

Avoidance is not as trivial

as it may seem. It places

stringent requirements

on a geofencing

mechanism

C9.3 - Assurance Level

Avoidance will always work or

there is an additional failsafe

in the case that is does not

G9.11 - Avoidance Guarantee

S8 - Introduce signals

The failsafe meets the

assurance level required

for the risk of stopping on a

level crossing

G9.13 - Failsafe Meets Risk

Human operators to work

or supervise crossings at

all times when trains are

active

S9.11 - Human Operators

Remote or automated

monitoring (particularly

with dependable vehicle

stopped on crossing

detection)

S9.12 - Remote Monitoring

Wireless interlock

S9.13 - Wireless interlock

An important aspect of

urban driving, but

requires significant

addition consideration

C9.1 - Undeveloped

A significant majority of

road incidents occur at

junctions. They represent

a general arbitration

issue which when it fails

leaves very little margin

for error. Tranfering this

process into a software

algorithm without further

support from infrastruct is

very challenging and

liable to failure with

potentially very serious

consequences. Junctions

have been grouped in to

three main types to aid

the decomposition of the

problem. They mainly fall

into controlled and

uncontrolled, with level

crossings being a special

case since it needs to be

coordinated with another

entirely different mode of

transport and industry

with different safety

standards

C9.0 - Navigate Junctions

A green traffic signal is only

an indication of priority not

that the way a head is clear

and safe. There may be

further complexities from

traffic queues and other

issues such as vulnerable

road users. Additional

sensing from infrastructure

with a more complete view

of the scene may help, or

pass the decision over to

infrastructure to manage

the whole junction to create

a single decision point to

reduce complexities

arising from system

interactions

C9.8 - Decision to Proceed

Requires further

development, but will

always be challenging

without moving to an

infrastructure control or

adopting the same

solution as signal

controlled junctions

C9.9 - Underdeveloped

Key

G – Goal

C – Context

A – Assumption

J – Justification



Sn – Solution

Undeveloped



v1.2


6.6 Pedestrian Crossing Arbitration (UP10)

Pedestrian crossings are perhaps one of the most challenging everyday aspects of operating a CAV in an

urban area. The pedestrians are not a compliant part of a system who can be directed and controlled and

will exercise free will which will be experienced as a random and chaotic variable to the automated system.

Unlike many of the potential obstructions on motorways, which are quite rare but still need to be

addressed, pedestrians are vulnerable and will be frequently and routinely encountered by CAVs operating

in urban areas, yet offer many behavioural and detection challenges as described by Colin Sowman in his

paper for ITS International in October 2016 and referenced in this article17:

Also relevant are the figures obtained by the UK’s Institute of Advanced Motorists which show that

despite the potentially fatal consequences, almost half of pedestrians knocked down by a vehicle

did not take enough care before stepping into the road. If pedestrians and cyclists know vehicles

(ADAS or driverless) will not hit them, they will walk or cycle across roads at will which could bring

city-centre traffic to a near standstill. While the increased safety is to be welcomed, additional

measures or legislation will be needed to control pedestrians and cyclists in order to keep the traffic

flowing.

This is a form of automation bias. The thresholds of expectation may move so that by trial and error people

may step out in front of moving vehicles that are moving at greater speeds with much less physical

clearance than before. This may be accelerated when coupled with the fact that people won’t feel the

need to worry about disrupting an empty running vehicle by forcing it to slow down or stop. There is also

the malicious aspect to defeat any cautious strategy which is put in place, also referencing Colin Sowman:

By simply walking out in front of a driverless vehicle, braking sharply ahead of it or placing cones

across a road, criminals could divert a driverless vehicle to hijack it, steal the cargo or rob the

passengers. This is particularly the case where the ‘driver’ cannot assume control.

From mischievous teenagers looking for a prank to impress friends through to people with more

malevolent intentions, knowing when to stop whilst keeping vehicle occupants secure is of concern. C-ITS

solutions are emerging now which may offer significant steps forward with the pedestrian detection

challenge for controlled crossings. The follow extract is from an article published by Neavia Technologies18:

…vehicles equipped with V2X technology can automatically receive alerts when pedestrians are

crossing or about to cross a road. This represents a significant step forwards for road safety: In

many situations, pedestrians are not visible by to car drivers. They can be hidden due to the road

configuration, or by other vehicles. They can also be less visible in case of fog, or under poor lighting

conditions. In those situations vehicles’ ADAS systems (Advanced Driver Assistance Systems) are

less relevant, or reacting extremely late.

The main concern for these approaches is their potential for inconsistency, as they are being offered to

bolster the vehicle’s own performance, rather like ADAS does for a human driver. If they are to be relied

17 http://www.itsinternational.com/categories/utc/features/the-downside-of-driverless-vehicles/ 18 http://www.neavia.com/2016-11-neavia-unveils-worlds-first-v2x-pedestrian-warning-solution/?lang=en]

http://www.itsinternational.com/categories/utc/features/the-downside-of-driverless-vehicles/

http://www.neavia.com/2016-11-neavia-unveils-worlds-first-v2x-pedestrian-warning-solution/?lang=en

http://www.neavia.com/2016-11-neavia-unveils-worlds-first-v2x-pedestrian-warning-solution/?lang=en


v1.2


upon then they need to be designed with this in mind, so that the vehicle’s systems can place the same

level of reliance on the infrastructure support each and every time a crossing is approached. This means

that both the pedestrian detection and the communication mechanism need to meet agreed minimum

performance standards rather than taking the current approach of ‘it will help when it can.’

The main theme of the module is that there is much which can be done with infrastructure to lower the

risks on dedicated crossings. Informal crossing on arbitrary sections of road will still incur risks from sensing

limitations, but these could be mitigated by improving public understanding and updating the Highway

Code and laws in respect of these technological limitations. In the same way that it is accepted that you

do not have a right to roam on railways, rather it is a form of trespass, some consideration to obstructing

traffic flow by being in the road may have to be given on the grounds of both safety and disruption. The

module considers three forms of crossing from fully signal controlled, through the rule controlled Zebra

crossing to general uncontrolled crossing which can take place almost anywhere.

The Pedestrian Crossings module is broken down into sub-modules, as shown in Figure 25.

Figure 25 : Urban Pilot GSN – Pedestrian Crossing Arbitration Module Structure

6.6.1 Zebra Crossings (UP10.1)

Zebra crossing are the main example upon which the other types of crossing have been derived from in

the GSN model. The technically simplest approach to zebra crossings would be to replace them with

signalled junctions, which are far more deterministic and do more to discourage people from just stepping

out or even running out on to the crossing. However, it may not be practical or cost effective to remove

or upgrade them all. One issue with them is understanding who has right of way. Vehicles are mandated

to stop when a pedestrian steps out on to the crossing, however pedestrians are supposed to wait for an

approaching vehicle to stop (to make sure it can and does stop) before crossing. If these rules were applied

literally by all parties, then either pedestrians would never be able to cross on busy roads or there would

be a stalemate whilst one waits for the other. Pedestrians are not compelled, as motorists are, to read the

Highway Code and there exists an option that pedestrians have an automatic right to cross no matter what

and only a sense of self-preservation prevents some people from walking out in front of a vehicle in a

stream of traffic with insufficient time for it to stop. It is left to the judgement of the pedestrian (who may

be a child with limited experience) whether a vehicle has enough time and distance to comfortably stop

without hitting them on the crossing.

UP10.1 - Zebra

(Pelican Puffin Toucan)

UP10.2 - Signalled

Sensing, reaction and arbitration with

pedestrians crossing and attempting to

cross the road

G10.1 - Pedestrian Crossing Arbitration

UP10.3 - Uncontrolled

Key

G – Goal

UP – Urban Pilot Sub-

Module




v1.2


The first challenge is to discourage pedestrians stepping out when there is not time to stop. It should be

borne in mind that any pedestrian detection system, no matter how good, may fail at some point so

prevention is better than cure in that pedestrians need to wait for the vehicle to demonstrate that it is

going to stop for them in sufficient time to allow them to cross. This could be achieved via an external

visual/audible HMI on the vehicle itself, or via the same HMI but mounted on or near the crossing. There

needs to be some conformance in the approach from vehicle manufacturers such that pedestrians become

accustomed to one clear message rather than various brand defining techniques, sounds and/or graphics.

For this reason, the crossing infrastructure approach has some appeal, but it adds the additional

complexity of requiring a failsafe mechanism for cars which do not announce themselves when

approaching the crossing. This would likely employ a similar mechanism to signalled junctions where the

vehicle must always know when it is encountering a crossing and expect a handshake before continuing

though at full speed. Further confusion may result from the mixture of legacy vehicles with CAVs. Just

because every approaching CAV has announced it will stop does not mean a manually driven vehicle’s

driver has noticed a pedestrian is on the crossing. A proceed to cross with caution message may help with

this as a reminder to those crossing the road that they should make the final visual check themselves.

More thought would need to be given to people being assisted by guide dogs.

The other part of the equation is pedestrian detection. This could be done from infrastructure, or from the

approaching vehicle. The issue with a vehicle based strategy alone is that it may fail to detect pedestrians

under some conditions, not least due to the limited field of view from the vehicle itself. A technically

superior solution would be to detect via infrastructure mounted sensors, with vehicle based detection also

used as a final resort in case a pedestrian runs out onto the crossing. Time-of-flight and infrared camera

pedestrian detecting sensors are being developed for infrastructure mounting and these offer the

reliability and robustness to adverse weather and light conditions and well as a good field of view when

appropriately mounted. Also, infrastructure based vehicle detection is already common practice. Having

the crossing itself as the one source of truth to perform the crossing arbitration seems an attractive option

for an assured system.

The Zebra Crossings sub-module is shown in Figure 26.


v1.2


Figure 26 : Urban Pilot GSN – Zebra Crossings sub-module (UP10.1)

External HMI. (Something

analogous to a front brake

light through to a full message

display)

S10.1.7 - Vehicle External HMI

Be able to give way and

allow pedestrians to

cross and react to reduce

collision likihood with

crossing pedestrians

G10.1.1 - Zebra Crossing

The Highway Code

states (Rule 19) that

pedestrians must wait for

vehicles to stop from both

directions before starting

to cross. Conversely it

also states (Rule 195)

that vehicle must only

stop when a pedestrian

has already stepped on

to the crossing. Despite

this many pedestrians

believe that they have

priority and may step out

without waiting.

C10.1.1 - Highway Code

J

A feedback mechanism

is needed to replace the

human eye contact

otherwise an apparent

slowing of a vehicle may

be missinterepreted as

a "I've seen you and I'm

stopping" signal

J10.1.2 - No Eye Contact

Pedestrians are made aware of

approaching vehicles and their

intentions

G10.1.5 - Pedestrian Awareness

Pedestrians waiting to cross

and already crossing are able

to be detected and

approaching (AV) vehicles are

informed

G10.1.4 - Pedestrian Detection

Vehicle Based Sensing

S10.1.4 - Detection From Vehicle

Infrastructure based sensing and

reporting

S10.1.5 - Detection From Infrastructure HMI present at the point of

crossing. Audio/Visual

warning or acknoledgement

related to approaching

vehicles ("Caution:

Automated Vehicle(s)

approaching")

S10.1.6 - Infrastructure HMI

Standalone sensing of

approaching vehicles

S10.1.8 - Vehicle Detection

Vehicle announces its

presenace and proximity

through V2I comms

S10.1.9 - Vehicle Comms

A consistent and reliable means to report all AVs

(not just the closest) and if it is known that they

are intending to stop (or not)

G10.1.8 - Approaching AVs are Always Reported

Method provides effective

arbitration between pedestrians

waiting to cross and

approaching AVs and

discourages 'step outs'

G10.1.9 - Arbitration is Effective

Presence of pedestrians

is relayed via V2I comms

to approaching vehicles

together with the wait

state of vehicles already

in attendance of the

crossing

G10.1.7 - Comms Relay

Performance targets are met for

detection and reaction (including

comms if used). Targets are set

against assesed risks of missed

detections and false detections

G10.1.10 - Reliability Targets are Met

Provide a range of sensing that

can be fused to measure and

detect pedestrians to a high level

of confidence

S10.1.10 - Robust Fused Sensing

False positive pedestrian detections

(stopping for ghosts) are avoided or

minimised to an accepable level

G10.1.11 - Minimise False Positives

Optimal Receiver operating characteristic

(ROCs) and sensor fusion tradeoffs are

achievable for required detection

performance

G10.1.14 - Sensing Tradeoff Performance

Real-world test library

from on-road trials

taken under all

intended road

conditions

Sn10.1.1 - Test Library

The detection error tradeoff (DET),

false negative rate (missed

detections) vs. the false positive

rate (false alarms) ultimately

determines the difference

between action and inaction both

of which can result in serious

consequences if chosen

incorrectly

C10.1.4 - Detection Error Tradeoff

Short notice 'step-outs' are

reduced to a minimum

G10.1.3 - Discourage Step-outs

Stop for pedestrians and other

applicable crossing users

G10.1.2 - Stop for Pedestrians

Detect and slow to a halt for

waiting pedestrians

S10.1.2 - Waiting Pedestrians

Decelerate and brake as

necessary for pedestrians who

are already crossing or who

may step out at short notice

when the ego vehicle has

commited to proceed over the

crossing

S10.1.3 - Crossing Pedestrians

A

Assumption that it will

not be possible to tell

AV and manually driven

vehicles apart. Cyclists

and other road users?

A10.1.2 - Differentiation

A

Some pedestrian crossings (signal

controlled) have already been fitted

with pedestrian sensors to influence

signal phase timing, so there is a

prior art

A10.1.1 - Pre-existing Ped Detection

User Trials under

controlled conditions

followed by

uncontrolled but

monitored trial

crossings on public

roads

Sn10.1.5 - User Trials

V2I comms can be relied

upon to a level

commsensurate with the

risk of failure under all


G10.1.13 - Robust Comms

Risk assesment of the HMI

working and not working

Sn10.1.3 - Zebra HMI HAZOP

Tests of the V2I comms

aound junctions under

active use conditions to

determine the likihood of

a comms outage or a

missed or late

notification

Sn10.1.4 - Useage Tests

Warning of an approaching vehicle is

sufficient without being able to indicate if it

intends to stop.

G10.1.12 - Simple Warnings are Effective

Sensing range and FoV are

always sufficient to detect

pedestrians in time to stop under

all operating conditions

G10.1.6 - Sensing Range and FoV

Remove Zebra crossings

and replace with signalled

crossings possibly

coupled with a Jaywalking

style regulation where AVs

are designated for use

S10.1.1 - Phase Out

J

The cost and complexity with

making Zebra crossing

workable and safe for all

road users might be

comparable to replacing

them with a crossing type

which has more

deterministic outcomes

J10.1.1 - Cost vs Complexity

J

Unexpected braking presents a

hazard to other road users and the

ego vehicle

J10.1.5 - Unexpected Braking Hazard

Risk assesment of

missed and false

pedestrian detections

Sn10.1.2 - Zebra HAZOP

J

It may be difficult to distinguish an

AV from a manually driven vehicle

without specific markings or a radio

beacon, therefore all approaching

vehicles can be reported, but without

knowing if they intend to stop

J10.1.3 - Difficult to Distinguish AVs

J

Some level of responsibility

will have to remain with the

pedestrian for the final

decision to cross. There is

a risk of complacency if the

cross indicates that it is

safe to cross when infact it

is not due to an undetected

AV which does not intend to

stop

J10.1.4 - Decision to Cross

19. No pedestrian shall

remain on the

carriageway within the

limits of a crossing

longer than is necessary

for that pedestrian to

pass over the crossing

with reasonable

despatch

C10.1.2 - Law

Drivers are required to

stop when a pedestrian

steps out, however

pedestrians should only

step out if there is

reasonable stopping

time/distance. As this is

subjective, some

pedestrians may have

poor judgement of this

and step out regardless

of the fact that the

approaching vehicles

may not be able to stop in

time. The ego vehice

must still be able to react

to these instances

C10.1.3 - Late Step-outs

Reliance upon

localisation is assured

G3 - Localisation

A

External HMI could form a vital part of

interaction with pedestrians to convey the

intentions that are lost from human-

human contact. However, consistency

between vehicles is very important since

any confusion created by differences in

the approach may be more dangerous

than having no external HMI

A10.1.3 - Standardisation of External HMI

Localisation has not

been integrated and

developed here but is

likely to form an essential

part of the reliance.

Similar dependencies on

localisation have been

further developed in other

parts of the model

C10.1.5 - Localisation

Key

G – Goal

C – Context

A – Assumption

J – Justification



Sn – Solution

Undeveloped



v1.2


6.6.2 Signalled Crossings (10.2)

This covers Puffin, Pelican and Toucan crossings and their other derivatives. The module borrows from and

links to zebra crossings and signalled junctions as aspects of both are required. The approaching vehicle

needs to be sure of the signal phase so the same solution should be adopted. Beyond that, pedestrians

may not wait for the correct signal phase and may cross late or early and run out to try to make it in time

before cars pull away. Electric Vehicles (EVs) will not have the running engine revving or restarting as an

early indicator that vehicles are starting to move off. For these reasons, much of the same logic is needed

as for zebra crossings, where pedestrian will attempt to cross at will so it can be treated as a traffic signalled

Zebra crossing. It is also suggested that the flashing amber phase is removed entirely since with pedestrian

detection the red phase is made longer. Having the ambiguity of the flashing amber phase only provides

opportunity for problems, leading to the vehicle needing to detect itself if there are any stragglers on the

crossing which may be prone to error. Different vehicles would potentially have different implementations

of this and it would be better left to the infrastructure with wider and dedicated sensing capabilities to

make the final judgement to proceed if clear.

The Signalled Crossings sub-module is shown in Figure 27.


v1.2


Figure 27 : Urban Pilot GSN – Signalled Crossings sub-module (UP10.2)

Stop when required at

signalled crossings. Be able

to give way and allow

pedestrians to cross during

flashing-amber phases as

well as managing 'step-outs'

at all times

G10.2.1 - Signalled Crossings

Handle the phase where it is allowed to

proceed if there are no more pedestrians

on the crossing

G10.2.6 - Pelican Amber Flashing Phase

"If the amber light is flashing and

there are no pedestrians on the

crossing, you may proceed with

caution"

C10.2.4 - Highway Code Rule 196

"Pelican crossings which go

straight across the road are one

crossing, even when there is a

central island. You MUST wait for

pedestrians who are crossing

from the other side of the island."


Be able to locate and detect the phase of

all encountered signals

G10.2.2 - Locate and Detect Signal Phase Pedestrians waiting to cross

and already crossing are able

to be detected and

approaching (AV) vehicles are

informed

G10.2.3 - Pedestrian Detection

Follow localisation and detection

GSN from Signalled Junctions

S10.2.1 - As Per Signalled Juntions

Follow pedestrian detection

methodology GSN from Zebra

crossings

S10.2.2 - As Per Zebra Crossings

Relevant HAZOPs and tests

extended or repeated from

'Signalled Junctions' as applicable

Sn10.2.1 - Junciton Tests Revisited

Relevant HAZOPs and tests

extended or repeated from

'Signalled Junctions' as

applicable

Sn10.2.2 - Zebra Tests Revisited

Proceed when there are no

pedestrians crossing and

(although not required by Rule

196) 'about to cross'

S10.2.3 - Proceed When Clear

Handle late crossing attempters

who may run out on to the

crossing with short notice

G10.2.7 - Late Crossing Attempts

Railings designed to

guide and protect

pedestians may hinder

the FoV of on-vehicle

sensing leaving a very

short time to react if

someone runs out to

make it on to the

crossing before the

green phase begins

C10.2.5 - Restricted FoV

Remove flashing amber phase

from light sequence

S10.2.5 - Remove Flashing AmberProvide an additional sensing

capability to the infrastructure to

detect late crossers, particulary

those running towards the

crossing threshold from a further

distance

S10.2.4 - Infrasturcture Support

Additional tests to exisiting

pedestrian detection to support

late crossing behaviours

Sn10.2.3 - Late Crossing Tests

Reduced ambiguity as to whether

the ego vehicle is allowed to

proceed

G10.2.9 - Reduce Amber Ambiguity

Infrastructure decides when

the flashing amber red phase

ends based upon sensing

the surroundings and the rate

at which the crossing clears

S10.2.7 - Variable Red Phase

J

Placing the 'go' decision on to the

infrastructure ensures a

consistent approach and reduces

FoV problems that could lead to

accidents occuring. Vehicles

would still be required to sense

that the path in fron tof them is

clear before proceeding

J10.2.2 - Increased Determinism

J

In everyday operation

pedestrians will still

attempt to cross while

vehicles are still

stationary up to and

including the point of

engine revving for

launch, therefore some

notion of 'about to

cross' must be

included for practicallity

and safety

J10.2.1 - Late Crossing

"When a steady green figure

shows, check the traffic has

stopped then cross with care.

When the green figure begins to

flash you should not start to

cross. If you have already

started you should have time to

finish crossing safely."


A

Flash figure phase (Rule 22) and

flashing amber phase (Rule 196)

are concurrent and coincident

A10.2.1 - Linked Flashing Phases

Provide an addtional deterrent (e.

g. loud tone or physical

barrier/indicator) to more strongly

discourage late crossing

attempts. This might be passively

or actively activated based upon

the pedestrian sensing strategy

S10.2.6 - Late Crossing Deterrent

Pedestrian detection equivalent to

Zebra crossings is sufficient

G10.2.5 - Zebra Ped Detection Reuse

Reuse of of signal location from

Signalled Junctions section is

sufficient

G10.2.4 - Signalled Junctions Reuse

The risk of a collision with a late

crosser or 'run out' event is

reduced to an acceptable level

from both a moving approach

and a standing start, without

unnecessarily exentending the

wait time

G10.2.8 - Reduced Collision Risk

Measures for crossing

management are effective for all

mixtures of traffic (AVs and

manually driven) under all


G10.2.10 - Measures Are Effective

Pedestrian behavioural study

around crossings

Sn10.2.2 - Ped Crossings Study

Monitored trials and tests of

complete crossing system

to determine effectiveness

Sn10.2.1 - Monitored Trials

Key

G – Goal

C – Context

A – Assumption

J – Justification

S – Strategy (yellow = singular, blue = one of

several options, red = concern over option, further

research needed)

Sn – Solution


terminology


v1.2


6.6.3 Uncontrolled Crossing (10.3)

This presents the most challenging in that as with other infrastructure crossings, there are no guarantees

the vehicle will sense every pedestrian every time. However, the lack of infrastructure means it will either

need to be handled from the vehicle or pedestrians are restricted from crossing away from designated

places. That would imply a Jaywalking law which from experiences from the USA, are often not adhered

to or rigorously enforced. There is also the issue of public acceptance of such a law as pedestrians hold on

to the notion of a right to cross anywhere, except motorways and railways. This is perhaps one area where

a drop in absolute safety (human to automated) may have to be conceded and might be addressed by a

public education programme to raise awareness. The real danger is one of automation bias because in the

clear majority of cases the automated system may perform as well or better than a human driver. This will

nurture a false sense of security and the public may start to assume an unrealistic margin of safety when

attempting to cross. As the threshold is pushed with regard to stopping distance, the risk of being hit due

to a sensing and perception insufficiency will increase. Ultimately the pedestrians hold their fate in their

own hands, but it may help to clarify the legal position away from the unrealistic position of expecting a

software based system to detect pedestrians 100% of the time under all conditions, and strongly

encourage the use of official crossings where they are provided.

The Uncontrolled Pedestrian Crossings sub-module is shown in Figure 28.


v1.2


Figure 28 : Urban Pilot GSN – Uncontrolled Pedestrian Crossings sub-module (UP10.3)

General attempts by pedestrians to

cross an arbitary section of road

G10.3.1 - General Pedestrian CrossingDeliberate and (currently)

legitimate crossing

attempts

C10.3.1 - Crossing Scope

Make it illegal to enter the

carriageway on-foot except on

crossings

S10.3.1 - Jaywalking Legislation

This may reduce the rate of

occurrence but is unlikely to

completely eliminate it due to

the practicality of enforcing it

C10.3.3 - Limit to EffectivenessProvide a feedback

mechanism to show

pedestrians that they have

been 'seen' and what

action is being taken

(stopping/slowing down)

S10.3.3 - External HMI

Public information

campaign

S10.3.4 - Public Awareness

The main risk is that it is

impossible to guarantee that

the sensing system will always

detect pedestrians and (as with

crossings) the abscence of

eye-contact creates a risk of

confusion with intentions. The

further risk is that the more

capable the system is the more

people will become complacent

and expectant that it will always

work due to 'Automation Bias'.

Unlike crossings, it would not

be possible to support vehicles

with pedestrian detection from

infrastructure on all sections of

all roads and 'soft' non-failsafe

mechanisms created with good

intentions may serve to

increase automation bias by

working on some occasions

and not others

C10.3.2 - Risks and Challenges

A

It will not be possible to completely guarantee the

safety of pedestrians who cross without care and

attention. Therefore, a proportion of the

responsibility for crossing (away from dedicated

crossing places) must be placed with the

pedestrian who must take ownership of their own

risk as the currently do. The difficulty is that the

driver is removed from an active role it may be

harder for pedestrians to understand or be as

aware of that risk. or pedestrians are

prevented/discouraged from crossing execept in

designated places as with the railway where the

inability of trains to stop is an accepted and

managed limitation

A10.3.1 - Failsafe Infeasibility and Risk Ownership

Follow on-vehicle pedestrian

detection methodology GSN from

Zebra crossings

S10.3.2 - On-vehicle Ped Detection

Pedestrian detection equivalent to

Zebra crossings re-evaluated to cover

general crossing

G10.3.2 - Zebra Ped Detection Reuse

HAZOP to consider any

issues of general context

crossing not caught by

Zebra crossing analysis

Sn10.3.1 - Extended HAZOP

Additional tests to cover

wider scenarios than Zebra

crossings

Sn10.3.2 - Additional Tests

Pedestrian collision rate and severity is

improved or not increased by the

introduction of AVs

G10.3.3 - Pedestrian Collision Incidents

Monitor Accident Statistics and effect

continous improvements to the

implemented strategies and

methods

Sn10.3.3 - Continuous Improvement

Library of real-world

general crossing

attempts for software

development and

testing

Sn10.3.4 - Test Library

Key

G – Goal

C – Context

A – Assumption



Sn – Solution



v1.2


6.7 Overtaking (UP11)

The overtaking module covers two way roads where vehicles cross over partially or fully into a lane

intended for on-coming traffic in order to, pass another vehicle or stationary obstruction. It covers more

than just the ego vehicle performing an overtaking manoeuver since it can itself be overtaken or face an

on-coming vehicle which is overtaking from the opposing direction. There are also situations where a so-

called undertake manoeuvre may legitimately need to be performed. For the ego vehicle the basic

message is to not attempt to overtake since the benefits do not outweigh the technical risks. Also in

practice some temporary infringement of the speed limit is often required to minimise the on-coming

collision exposure time, but this as an unlawful action and is difficult to sanction from an algorithmic

perspective. However, in certain circumstances it may be impractical for the ego vehicle to not overtake

in order to make reasonable progress such as when following behind slow moving road users (cyclists, road

maintenance machinery) or stationary obstructions such as rows of parked cars.

When being overtaken it may become necessary to slow down to allow the overtaking vehicle to move

over early if it meets an on-coming vehicle unexpectedly. This may be the fault of the vehicle performing

an unsafe overtake, but some drivers do so expecting to be able to force their way back in if needed. In

the interests of trying to prevent serious head-on collisions there may need to be some situation

recognition and response which could be described as road etiquette, but this may diminish its potential

seriousness. An option is to not do anything and hope drivers learn or are informed of this new potential

risk from CAVs when performing overtakes.

Whichever overtake is being considered, the sensing performance needs to be capable of detecting and

responding to the higher closing speeds involved which could as high as 70 mph for a 30 mph speed limited

road. Sensing and sensing fusion techniques (where used) must be shown to be able to handle the scan

and frame rates needed for situation recognition at these speeds otherwise the ego vehicle is not fit for

operation in unsegregated two-way traffic.

For passing a stopped vehicle, understanding when a vehicle has actually stopped, with the intention of

being passed may be much more difficult that it first seems. A vehicle may be have stopped to set down

passengers, or to allow another larger vehicle to pass from the opposite direction. Simply assuming it has

stopped and is not waiting for something in the road ahead and pushing past might cause considerable

disruption. Some visual or V2V indication of its intentions would help with this, but may require

modification of the entire existing vehicle parc to be effective.

Undertaking of stationary vehicles which have stopped waiting to turn right or for loading reasons on one-

way streets may be necessary on some routes. Determining the correct context and ensuring sufficient

space to do so are challenges to be overcome.

Additional consideration to passing cyclists is needed as they have some of the elements of vulnerability

and unpredictability in common with pedestrians.

The Overtaking module has been split into sub-modules, as shown in Figure 29.


v1.2


Figure 29 : Urban Pilot GSN – Overtaking Module Structure

The sub-modules are shown in Figure 30 to Figure 32.

G11.1 - Overtaking

M11.1 - Other Vehicles Overtaking M11.2 - Perform Overtake M11.3 - Undertaking

The types of scenario

involving overtaken have

been divided into three

groups. It is possible to

be affected by others

overtaking, the ego

vehicle itself may need to

overtake to not be

obstructed, and there are

occasions when passing

on the near side is

legitimate and necessary

which is a special class

of overtaking informally

called "undertaking"

C11.0 - Overtaking Key

G – Goal

C – Context

M – Sub-Module




v1.2


Figure 30 : Urban Pilot GSN – Other Vehicles Overtaking sub-module (UP11.1)

Being overtaken where it

involves temporarily

crossing over into a lane

normally intended for

travel in the opposite

direction

G11.1.5 - Being Overtaken

Restrict overtaking to where an unreasonably

(to be defined quantitatively, e.g. 10 mph)

large differential speed exists between the

lead vehicle and the speed limit

S11.1.8 - Restrict Overtaking: Relative Speed

Attempt to behave appropriately with the

caveat that the 'overtaker' takes responibility

for the additional risk of overtaking a vehicle

which may act with a lower contextual

awareness

S11.1.3 - Attempt to Respond AppropriatelyTake no action with the

acceptance that the

number of head-on

collisions may increase

until the AV fleet

significantly out numbers

the manually driven fleet

S11.1.4 - Take No Action

Overtaking may be less of

an issue in an urban conext

than with other higher

speed routes, but still

needs to be considered

C11.1.3 - Urban Overtaking

Overtaker travelling in the same

path (head-to-head) from the

opposite direction.

G11.1.6 - Head-to-Head Scenario

Recognise when the vehicle in

front is approaching in the

same lane and reduce speed

accordingly to mitigate a

collision

S11.1.5 - Situation Recognition

The ego vehicle being overtaken

where it involves temporarily

crossing over or encroaching into a

lane normally intended for travel in

the opposite direction

G11.1.2 - Other Vehicles Overtaking

The performance of the

sensing and localisation

performance is sufficient to

work with the braking strategy

G11.1.12 - Sensing Capability

The braking strategy

adopted is effective and

workable along side the

sensing capability

G11.1.13 - Braking Strategy

Use proving ground

controlled conditions to

verify and validate the

response performance

Sn11.1.5 - Track Tests

J

The ego vehicle's detection system must be

able to locate itself and estimate the position

of the approaching vehicle on its map to

understand if they are using the same lane

and are potentially on a collision course. This

places requirements on the performace of

mapping, localisation, range and velocity

estimation of the approaching vehicle

J11.1.5 - System Performance Reliance

Collisions resulting from AVs being

overtaken do not reach unacceptable levels

G11.1.10 - Collisions Remain Within Limits

Proving Ground tests

where a testable

strategy is used

Sn11.1.3 - Track Tests Monitoring of accidents to

ensure AVs are not inducing an

unreasonable increase in

overtaking related accidents

Sn11.1.4 - Statistical Monitoring

The new risks due to AV

interaction with existing

road users may be twofold.

The first is AV behaviour

(possibly more prudent

slower progression rate)

may induce more

overtaking in general from

manually driven vehicles.

Secondly, the response to

being overtaken (even if

that is no response) may

increase the risks to the

overtaker, making it harder

to abort or pull in for

instance

C11.1.4 - Interaction Risks

Where the manoeuvre requires

encroaching upon an lane intended for

use by vehicles travelling in the

opposite direction at >20 mph, for all

vehicles, restrict overtaking to passing

stationary and slow moving

obstructions (<=10 mph) and enforce

that a slow speed (e.g. max 20 mph)

manoeuvre is performed

S11.1.2 - Restrict Overtaking: Absolute

J

Limit the closing speed to on-coming

traffic. This reduces the criticality and

performance upon sensing

requirements, but will increase the

exposure time as the manouvre will take

longer

J11.1.4 - Limit Head-on Closing Speeds

A

As with all rules of the road,

many motorists will

intentionally break them and

emergency vehicles may

also do so legitimately.

Consideration would need to

be given to the risks

(frequency and severity) in

these cases

A11.1.1 - Breaking the Rules

The sensing performance and functional

integrity of the sensing and processing system

on the ego vehicle for detection of on-comming

traffic meets that required for the selected

strategy (and the resulting hazard exposure)

for handling other overtaking vehicles

G11.1.9 - Sensing Performance and Criticality

Sensing system design

and test documents,

(SRD, FMEA)

Sn11.1.1 - Sensing Design

Sensor system HAZOP

section for being overtaking

Sn11.1.2 - Overtaken HAZOP

Key

G – Goal

C – Context

A – Assumption

J – Justification


Sn – Solution



v1.2


Figure 31 : Urban Pilot GSN – Perform Overtake sub-module (UP11.2)

Parked or Stopped Vehicles

G11.2.4 - Lane Width Restrictions

<=10 mph

G11.2.2 - Slow Moving

"Double white lines where the

line nearest you is solid. This

means you MUST NOT cross or

straddle it unless it is safe and

you need to enter adjoining

premises or a side road. You

may cross the line if necessary,

provided the road is clear, to

pass a stationary vehicle, or

overtake a pedal cycle, horse or

road maintenance vehicle, if they

are travelling at 10 mph (16 km/h)

or less. "


Long rows of parked cars on two-way roads

(which effectively make the lane unusable)

G11.2.7 - Passing Parking and Narrow Lanes

Use One-way systems to

remove narrow lanes and

opposing traffic motion

S11.2.4 - Use One-way Systems

Prohibit or restrict parking

(allow only loading and

short waiting)

S11.2.5 - Remove ParkingUse alternative routes for AVs to

avoid using roads with restricted

widths

S11.2.513 - Narrow Road Avoidance

Single parked or waiting vehicles,

or other limited static obstruction

G11.2.8 - Pass Stopped Vehicles

Certain areas have residential

parking bays lanes in the public

road in front of houses that don't

have dedicated off-street parking.

These lanes often encroach upon

the normal driving lane making it

too narrow to drive without

staddelling the lane of the

opposing direction. This makes it

difficult to proceed depending

upon how vehicles have been

parked and the width of on-coming

vehicles. Some drivers may opt to

wait whilst others may proceed

relying on the on-coming traffic to

slow down or give way and a point

where both vehicle have space to

pass each other

C11.2.13 - On-street Parking Bays

Road widening is seldom

practical without narrowing

or removal of pedestrian

footpaths

S11.2.14 - Road Widening

Enforce gaps in parking rows so that

AVs can make progress. May require

active management using parking

place sensors to ensure gaps exist

S11.2.15 - Use Passing/Waiting Places

Signal control traffic through

narrow sections to ensure

passage in both directions. May

benefit from V2I to selectively

activate for AVs

S11.2.16 - Signal Control Traffic

Be able to overtake when

necessary in certain limited

cases

G11.2.1 - Perform Overtake

Be able to determine when a vehicle has

stopped (pulled in/over) and is waiting or has

parked. Can distinguish when a vehicle has

only momentarily stopped (for instance, to

allow an on-coming vehicle to pass)

G11.2.9 - Detection of a Stopped Lead Vehicle

Require all vehicles to have a

'running' indiction. For

existing vehicles: Tail lights

on when driving by

convention, hazard lights use

when waiting (and expecting

other vehicles to overtake),

tail lights off when parked or

stopped, Possible use of V2I

comms for new vehicles. Do

not attempt to overtake any

vehicle displaying a 'running'

conditon unless a significant

timeout period of waiting has

elapsed

S11.2.21 - Running Indication

A

A software update may be

required for existing

vehicles which have an

auto-lights function whereby

daytime-running lights

operate without tail lights

during daytime conditions

A11.2.1 - Software Updates

"Parking in fog. It is especially

dangerous to park on the road in

fog. If it is unavoidable, leave your

parking lights or sidelights on."


"Cars, goods vehicles not

exceeding 2500 kg laden weight,

invalid carriages, motorcycles and

pedal cycles may be parked

without lights on a road (or lay-by)

with a speed limit of 30 mph (48

km/h) or less if they are:

* at least 10 metres (32 feet) away

from any junction, close to the kerb

and facing in the direction of the

traffic flow

* in a recognised parking place or

lay-by.

Other vehicles and trailers, and all

vehicles with projecting loads,

MUST NOT be left on a road at

night without lights."


"All vehicles MUST display parking

lights when parked on a road or a

lay-by on a road with a speed limit

greater than 30 mph (48 km/h). "


Difficulites may arise when both rear

indicator lamps are not visable to

following traffic due to obstructions

such as parked cars

C11.2.8 - Hazard Lamp ObscurationInstances of traffic flow

distruptions due to AV narrow road

arbitration are acceptably low as a

result of the measures in place


Width restricted areas, or

'bottlenecks' are reviewed on a

case-by-case basis for cost-benefit

and practicality. It is suggested that

a process of route approval is used

and that non-approved routes are

avoided altogether by AVs

Sn11.2.7 - Route Approval Process

When considering if a

vehicle has stoped, parked,

pulled-in or is simply giving

way to an on-coming

vehicle, a human driver will

make a decision based

upon their own discretion

and their own personal

assessment of the risk of

making a mistake. Cues

such as exhaust fumes,

interior/exterior lights and

occupant movements will

help to inform their decision

but are too subtle for

machine detection to work

reliably

C11.2.12 - Driver Discretion

Overtake only when required to do so to not be

obstructed from making reasonable progress.

(Do not overtake a slower moving vehicle just

to improve the rate of progression as the risks

and complexity are not warranted for the benefit

even if progression is kept suboptimal)

S11.2.1 - Overtake Only if Blocked or Impeded

J

Generally overtaking

represents an

unreasonably high risk for

the level of complexity and

the benefit it brings.

However, there are certain

situations where it cannot

be avoided to ensure

reasonable progress is

made toward the

desination, or to prevent the

ego vehicle from becoming

'stuck' in a location

J11.2.1 - Unnecessary Risk

Drivers are compliant if required to

change behaviours and machine

detection is dependable enough to

not cause unreasonable traffic

distruption or exended journey

times


Driver exceptance survey

or study to test if any

new driver actions are

dependable and

workable

Sn11.2.9 - Driver Survey

On-road trials for a

wide variety of

locations and

conditions

Sn11.2.8 - Road Trials

Assessing the current

situation before an overtake is

performed is a signifiant

challenge. For example

complex scenarios can

emerge from seemingly

simple ones such as if

attempting to overtake a single

stopped vehicle then results in

the need to overtake several

more. Also if a queue forms in

front of a stopped vehicle

which the ego vehicle is

attempting to pass, it could be

left stranded in the path of on-

coming vehicles

C11.2 - Contextual Complexity

Vehicles and road users

travelling at slow speed could

result in an AV unreasonably

creating a tailback if it is not

provided with an overtake

strategy. A significant part of

the problem is not knowing in

advance if the slow road user

will conintue to follow the

same route as the AV intends

to. This could result in an

unnecessary overtake attempt

when just waiting would have

resulted in a better outcome

C11.2.5 - Tailback Prevention

Employ a suitable passing

strategy: If sufficient

clearances are present to

pass at the current nominal

speed then proceed to pass

immediately. Otherwise

slow behind and wait for a

period of time related to the

current traffic density before

attempting to overtake as

conditions permit

S11.2.22 - Passing Strategy

J

As traffic density

increases then the

overall benefit of

overtaking deminishes

so a long wait time is

permissable.

Conversely, there is no

point slowing behind a

cyclist on an otherwise

empty road where there

is suffiecient space to

pass safely

J11.2.2 - Traffic Density

Overtaking creates significant

additional risk due to the realtive

closing speed between vehicles

approaching from opposite

directions. A 30-40 mph

collision risk could become a

60-70 mph collsion. Requried

reaction times and stopping

distances are signifiacntly

impacted

C11.2.9 - Head-on Collision Risk

The selected strategy for deciding when

to execute the pass manouvre of the

overtake is workable, effective and

maintains the risk of a collision within

acceptable limits

G11.2.12 - Passing Strategy is Effective

Trials on proving ground then

on public roads to determine

effectiveness

Sn11.2.12 - Supervised Trials

The sensing performance and functional

integrity of the sensing and processing system

on the ego vehicle for detection of on-comming

traffic and tracking of the slower road user

during the overtake, meets that required for the

selected strategy (and the resulting hazard

exposure) for handling overtaking slow moving

road users

G11.2.11 - Sensing Performance and Criticality

Sensing system design and test

documents, (SRD, FMEA)

Sn11.2.10 - Overtake Sensing DesignSensor system HAZOP

section for being overtaking

Sn11.2.11 - Overtake HAZOP

Simuation Study against the

software intended for use

Sn11.2.13 - Simulation Study

S11.2.17 - Reverse Back S11.2.18 - Bi-directional Vehicle

Historic parking map, kind of

'heat map'

S11.2.19 - Parking History MapConsider fixed routes

with problem spots for

people stopping and

parking

C11.2.7 - Fixed Routes

The ego vehicle must be

able to detect and

classify cyclists on the

carriageway under all


G11.2.5 - Detection

If the cyclist is travelling at

or below 10mph an

overtake attempt should

be made at a suitable

point in order to make

reasonable progression

G11.2.6 - Overtaking

Able to detect if the cyclist

is signalling to turn

G11.5 - Hand Signals

Test case library of cyclist detections

under varying conditions

Sn11.2.23 - Cyclist Detection Library

G11.2.3 - Passing Cyclists

Drive appropriately around

cyclists

S11.2.2 - Appropriate Passing

Alterative Routing and prohibition

and segregated cycle lanes

S11.2.3 - Restrict Cyclist Road Use

"Motorcyclists and cyclists

may suddenly need to avoid

uneven road surfaces and

obstacles such as drain

covers or oily, wet or icy

patches on the road. Give

them plenty of room and pay

particular attention to any

sudden change of direction

they may have to make."

C11.2.14 - Highway Code 213

A

Unlikely to be accepted

or practical to provide

segregation

everywhere particularly

in the early stages of

CAV adoption

A11.2.2 - Cyclists

Key

G – Goal

C – Context

A – Assumption

J – Justification



Sn – Solution

Undeveloped



v1.2


Figure 32 : Urban Pilot GSN – Undertaking sub-module (UP11.3)

Undertaking of right-

turners and right-hand

stopped and stranded

vehicles (e.g. loading or

broken down on one-way

or multi-lane streets)

G11.3.1 - "Undertaking"

"...only overtake on the left if the

vehicle in front is signalling to

turn right, and there is room to do

so"


Look for obvious cues that

the stopped lead vehicle is

not going to move such as

hazard lights on, or

partially mounted on the

kerb, upon which

algorithmic heuristics may

be built

S11.3.2 - Use Visual Cues

A

Stranded or deliberately

but illigitimetely parked

vehicles normally use the

hazard warning lights and

this can be further

incouraged or enforced

A11.3.2 - Hazard Light Use

Vehicles and other stationary

obstructions may be passed on

the inside/left lane when safe and

appropriate to do so

G11.3.2 - Safe Near-side Passage

Infrastructure, backoffice, via a V2I

comms link or occpant initiated (HMI)

manoeuvre

S11.3.1 - Remote Override Mechanism

A

Prevent being stuck beind a broken down

vehicle or loading lorry. For unoccupied

vehicles, this could create a requirement for a

dependable resilient comms link and live

camera feed to allow a fleet managing back

office to dictate behaviour (i.e. not direct

teleoperation, but still human intervention).

Could alternatively provide an override HMI to

the user/occupant otherwise the vehicle just

waits, but this passes responibility to

potentially unqualified or incapable occupants

A11.3.1 - Prevent 'Getting Stuck'

J

There are occasions where passing on the inside of a

vehicle is necessary to continue to make progress and

not become unnecessarily stranded. Recognising the

conditions for where is should or should not be used in a

way which can be expressed in an algorithmic rule set is

the challenge

J11.3.1 - Necessary In Certain Circumstances

Measures are workable and

effective


Scenario library from video

and sensor data used to

assist learning, regression

testing and optimisation of

heuristics

Sn11.3.1 - Scenario Library

Key

G – Goal

C – Context

A – Assumption

J – Justification



Sn – Solution

Undeveloped



v1.2


6.8 Antisocial Behaviour (UP12)

The Antisocial Behaviour module covers some of the operational issues which should fall outside normal engineering

considerations but which may throw up some real-world practicalities that cannot be avoided and may in turn require

solutions to be engineered. The change of use from an owner driven vehicle to a possibly fleet owned and operated

vehicle which can be operated unoccupied presents many new opportunities for people to cause disruption. There

is a process of depersonalisation that may take place when firstly there is no longer a person driving the vehicle to

offend and secondly, it may not even have anyone in it to directly observe the treatment of it from outside. From

impatient drivers and pedestrians unafraid to force an empty vehicle to a halt, there are more concerning issues of

criminal uses of the vehicle which might have been facilitated by its automation. Many of these concerns are related

to the unoccupied running of the vehicle, but there are also potentially valid concerns that an automated vehicle may

have personal security issues, the main fear being that drivers will be demoted to helpless and hapless passengers

vulnerable to attack. This arises from the fact that an urban AV could be stopped and surrounded by any group of

people who may have malicious intentions towards its passengers. With existing vehicles, assailants run the risk that

the target vehicle may just not stop, or if it does stop, the driver may proceed to force the vehicle past to escape

what they perceive to be a dangerous situation. Instructing an automated vehicle to do likewise quickly becomes

problematic if not also unlawful. Many of the issues addressed are covered by laws and could be left to existing law

enforcement methods, or the enforcement of laws that have been created or updated accordingly. However, laws

are often not enough of a deterrent as people usually do not intend to get caught and there is the burden and

practicality of proof since identifying the perpetrators of the identified antisocial behaviour after the fact may be a

significant challenge such that, to those who may be affected, prevention is better than cure or retribution.

Figure 33 : Urban Pilot GSN – Antisocial Behaviour module (UP12)

G12.1 - Antisocial Behaviour

It is anticipated that a number of

antisocial behaviours may emerge

presented towards or resulting from the

use of AVs.

Some of these behaviours will arise from

the removal of the driver from the vehicle

whilst others will result from run-empty

vehicle as the lack of direct supervision

opens new opportunities for exploitation.

Many of the issues are already covered

by appropriate laws and enforment,

however practically additional strategies

may be needed for prevention and

deterrent purposes.

C12.1 - Antisocial Behaviour Emergence

Cyber threats and pre-purposing

of vehicles through modification

are not included. These are valid

threats but under consideration

is the exploitation of the normal

vehicle operation or inherent

weakness in operation to ill

effect

C12.2 Normal Vehicle Operation

M12.1 - Pedestrians M12.2 - Other Vehicles M12.3 - General M12.4 - Agents

Key

G – Goal, C – Context, M – Sub-Module



v1.2


The Antisocial Behaviour module structure is shown in Figure 33. The structure was derived from common the themes

emerging from the issues mind map shown in Figure 34.

The Pedestrians sub-module covers the issue of wilful obstruction of the ego vehicle by pedestrians and bystanders

or even people with malicious intentions. This can range from people who may feel some level of indignation towards

moving out of the way for a machine, impatience to wait to cross, particular from the perspective of a crowd surge

where safety in numbers may prevail, though to a deliberate surrounding of the vehicle by people who may wish to

try to force entry into it, knowing that it will not run them over. Once fairly benign measures have been exhausted

such as horn equivalents, play a reminder jingle or please move audio message there needs to be an approach to

proceeding. A human driver would use due diligence to move forward based on the urgency of the situation and

possible use of gestures or eye contact. The proposed solutions are to emulate human driving behaviour by providing

a nudge forward mode for crowd conditions and a push forward mode for more serious situations which may

threaten the personal safety of the occupants. Obviously, the vehicle cannot be programmed to force its way past

people if there is a risk of injury to them. The Nudge forward mode would use a creep speed and sensing to detect if

people became too close to the vehicle. With the provision of this additional sensing it is conceivable that it could

still be allowed when the vehicle is unoccupied as anyone refusing or unable to move would still ultimately prevent

the ego vehicle from going any further in that direction. The Push Forward mode is potentially more controversial

and it is anticipated that it would be only be appropriate and permitted for use in dangerous or threatening situations

for which the vehicle user would be required to take responsibility for. It would therefore have to be initiated and

modulated by a vehicle occupant and would not apply to unoccupied vehicles. In effect a limited manual override

supported by vehicle systems and monitoring which could possibly provide evidence to support its use after the fact.

The level to which the function could be allowed to physically force people out of the way is laid out in the GSN. It

could be supported by sensing and trappage prevention/detection measures to prevent it being used to inflict

deliberate harm (the other side of the argument addressed in the Agents sub-module under vehicle misuse). The

mode is effectively for emergency escape but carries with it equivalent risks that it could be intentionally or

unintentionally misused. Measures put in place to help prevent it could cause someone to end up crushed under the

vehicle’s wheels or underbody which could also limit its effectiveness in the most severe of scenarios which is another

ethical and legal trade off to be considered.

The Other vehicles sub-module covers the anticipation of issues arising from interaction with conventionally driven

vehicles. As with the rest of the module, much of the problem could be attributed to the depersonalisation of

interacting with a machine rather than a person. The machine cannot take offense at being forced to break or the

right of way not being respected, particularly if also there are no vehicle occupants to be perturbed. The sub-module

breaks up the potential behaviours into aggressive driving, testing for weaknesses (in order to exploit), herding and

trapping, as well as induced collisions. Testing for weaknesses involves trying to trigger or induce behaviours that

might be used later for ill effect, but might in itself be dangerous as an activity if the limits are pushed too far or the

driver(s) involved lose sight of the effects of their own driving whilst concentrating on perturbing the ego vehicle.

Motivations may vary from pranks to looking for some future advantage to gain position in traffic flow, “how late can

I leave it to jump out on an AV?” for example. Herding or trapping are both similar to testing and may result out of

testing, but could have serious consequences if it is found to be able to effectively force a route change of the ego

vehicle which could form part of a wider criminal activity. Mitigations and prevention for such activities is difficult

beyond trying to detect and report foul play with the ability to do so perhaps acting as a deterrent to try in the first

place. Finally, induced collisions used in much the same way are they already are, for compensation claims, but with

the added incentive that there may not be a human witness in the ego vehicle and that there is a control system to

be falsely accused resulting in the so-called ‘Autonomous Scapegoat’. Inducing a collision with an AV might be done

to discredit the general use of AVs or again just for financial gain.

The General sub-module covers general interference such as vandalism (of the kind which effects the vehicle’s

operation, not cosmetic/graffiti), deliberate obstruction and disablement attempts as well as pranks conducted for

amusement or the irony of exploiting some aspect of there not being a human driver. Pranks may include ‘playing


v1.2


chicken’, by seeing who is brave enough to jump into or out of the way of the ego vehicle at the shortest moment.

Also, attempting to attach items or tow another vehicle, hanging on to the outside for a ‘free ride’ as well as trying

to surf or balance on a moving vehicle for peer or social media notoriety. Finally, when the vehicle is unoccupied,

particularly if obviously fleet operated (thus depersonalised from an individual owner or potential victim), there may

be the temptation by some to stop it in its path and attempt to overturn it or displace it to a new location to see how

it copes or to create a photo opportunity by placing it in a place or position of some novelty. Many of these are not

entirely new issues, but are perhaps made easier or more tempting when there is nobody inside the vehicle. They

could still be left to regular law enforcement, but the lack of witnesses may make it less of a deterrent and harder to

pursue after the fact, with prevention being better than punitive measures. Reporting of events via a control centre

might be a viable option to deter these kinds of pranks that do not have any serious criminal intentions beyond

property damage or risking injury.

The Agents sub-module provides coverage for where the AV is being utilised directly to facilitate some criminal or

unwanted behaviour. It further breaks down such activity into terrorism, as a transport mode for general criminality,

as a mobile surveillance device, and where the vehicle itself is used either as a weapon or to try to create some form

of accident for which it can then be blamed.

Taking terrorism first, car bombs are not new, but there is a new potential to be able to send one or more vehicles

to a location to deploy some explosive device or chemical/biological agent, or to just create congestion near a

targeted area to amplify the effects of a separate act of terrorism. As far as transport for general crime is concerned,

taxis and so-called minicabs already present traceability issue for police as assailants can commit a crime then use a

minicab to leave the scene of a crime whilst paying cash so that there is no payment record. The rollout of AVs

presents a new opportunity for a convenient escape with potentially even less traceability. In addition, vehicles could

be easily equipped with cameras (for example ‘dash cams’, action cameras and smart phones) then sent to a location

to monitor or stalk either persons or places of interest for future crimes. Deliberate misuse of the vehicle by

occupants wishing to inflict harm remains a possibility depending upon how the system’s overrides (if any) have been

implemented. If it is possible for the users to have some form of manual control, then these could potentially be

exploited to cause harm. The possibility of user induced accidents (for so-called scapegoating) beyond the use of

basic low-speed overrides has not been developed, since by definition of the feature this should not be readily

possible without modification to the vehicle which is also out of the scope of consideration. Countermeasures to

these types of threats and issues are difficult and will depend on the seriousness and likelihood of occurrence for the

intended region of use. Where there is not a strong possibility of frequent occurrence then it could be left to regular

law enforcement. If more pre-emptive or preventative measures are required, then active fleet monitoring, spot

checks and similar impositions may be required and will have to be considered in balance with the possible

infringement of civil liberties and the right to personal privacy.


v1.2


Figure 34 : Mind Map for Antisocial Behaviour Involving AVs

Suicide Attempts

Throwing liquid over the vehicle to disable it

(oil, paint etc)

By externals

(through coercion,

or provocation)

By occupantsDeliberate miss-use of

countermeasures

(e.g. nudging forward)

'Playing Chicken'

Seemless transfer between vehicles

Unconspicously arrive or leave a crime sceneUse as a 'Getaway' car

Abduct passenger(s)

Steal vehicle or contents

Narrowly avoiding collisions

Ride Hitching

(hanging onto the outside)

AV Surfing

(standing on the roof, bonet/hood, boot/trunk)

Mistreatment/Misuse

of AV by Individuals

Induce congestion or denial of service

(possibly to compound another terrorist act)

Remote stalking, snooping or 'case a joint'

(reconnaissance of potential crime targets)

Use of AV as a Proxy/Agent

for Criminality

Remote monitoring/surveillance

Disperse a biological or toxic agent

Deploy a bomb

Terrorism

Gain attention, sympathy, notoriety,

or to gratify a masochistic aim

Financial reward or gain

Damage to AV manufacturer's reputation

Attempt to demostrate a safety concern

(real or contrived)

Instigate/induce a crash with an AV

Gain proximity to VIPs and

notorious individuals

(celebrities or alledged criminals)

Pranking

Road Rage

Non-contact hijacking

(forced route change)

Towing/hitching (save fuel, free ride, joke)

Trapping

Herding

Testing of AV behaviours and

responses to find weaknesses or limits

Playing Games

Not respecting the right of way

Unreasonable overtaking/passing of AV

Agressive driving with respect to the AV

Mistreatment of AV by

Conventional Drivers

Small group stood in the way

with willful indifference

(nonchalance;

stood in the way chatting, smoking)

Crowd surge

(shopping areas,

sports stadium/concert

event ending)

Individuals

(lazy crossing,

luck chancing)

Arbitary Obstruction

of AV by Pedestrians

Conduce or coerce

(sell or solicit something,

sign autograph or petition,

windscreen/shield wash, prostitution)

Delay

Robbery

Assault

Group Surrounding of AV

to Trap Occupants

Antisocial Behaviour

Involving AVs


v1.2


Figure 35 : Urban Pilot GSN – Antisocial Behaviour Pedestrians sub-module (UP12.1)

Including groups and

individuals 'on foot'

G12.1.1 - Pedestrians

Deliberate entrapment

G12.1.3 - Group Surrounding

Crowds, groups, or individuals

G12.1.5 - Forced Road Crossing

G12.1.2 - Wilful Obstruction

Penalty for wilful obstruction.

"If a person, without lawful authority or

excuse, in any way wilfully obstructs the

free passage along a highway he is guilty

of an offence and liable to a fine not

exceeding level 3 on the standard scale."

C12.1.1 - Highways Act 1980 Section 137

One or more individuals stood

in the highway with willful

indifference to allowing the AV

to pass

G12.1.4 Unwillingness to Move

Activate deterrent

messures such as high-

pitched noise (mosquitto

alarms), soaking water

mist/spray

S12.1.1 - Active Deterrents

A

Nuisance deterrents could

be couter productive and

present a provocative and

adviserial challenge. High

frequency noise most

effective for under 25 year

olds but could cause

hearing damage if loud

enough to be effective.

Water mist could be

blamed for damage to

property.

A12.1.1 - Provocation Risk

Audible requests and

warnings or jingles

S12.1.3 - Passive Deterrents

Edge forward at a creep speed,

mimicking existing driver

behaviour

S12.1.4 - Nudge Forward Mode

Risk of trappage and

crushing is minimised to

an acceptable level

G12.1.8 - No Trap Hazard

J

May have to inhibit control

reactions to normal driving

sensing, therefore without

additional measures there is a

risk of feet being crushed under

road wheels and other forms of

trappage

J12.1.4 - Inhibit Driving Reactions

Fit wheel fairing covers to

reduce likelihood of

entaglement or driving

over feet/toes

S12.1.9 - Wheel Covers

A

Wheel covers may have to

be close to the ground to be

effective at preventing foot

roll-over, but this may be

impractical due to road

unevenness and jamming

on debris

A12.1.3 - Ground Clearance

Wheel arch vacinity and underbody

sensing, bumper pressure sensing

S12.1.7 - Proximity and Contact Sensing

A

Might be difficult to

implement in a practical way

to achieve a trade-off that

does not compromise either

the safety of people or the

reliability of the vehicle

A12.1.2 - Practicality Issues

J

People in very close

proximity and in contact with

or under the vehicle will

likely be unseen or

undetectable by normal

driving sensing, therefore

near field and underbody

sensing is required

J12.1.3 - Near Field Sensing

Emergency push forward at

limited speed then sprint

away when the forward path

is clear

S12.1.2 Push Forward Mode

J

Use only when vehicle is

occupied and passenger(s) are

perceived to be in immediate

danger

J12.1.1 - Passenger Protection

Prevent the risk of person

(s) in front of the vehicle

being pushed off their feet

then being run over by the

ego vehicle

G12.1.6- Prevent Run Over

Careful use of progressive and

limited speed combined with

anti-trap sensing

S12.1.6 - Careful Speed Control

Passengers are provided with a

manual intervention control

used to force the vehicle

forward in threatening and

dangerous situations. The user

is responsible for any injuries

caused or misuse of the

intervention facility

S12.1.5 - Passenger Discretion

Passengers understand how

to operate the user

intervention and their

responsibility for the

consequences of doing so

G12.1.7 - User Responsibility

Use prerecorded instructions

to the user, multi-modal

voice/visual if required

S12.1.11 - Internal Messaging

Provide live assistance from a

remote support centre if it can be

made immediately available

S12.1.10 - Control Centre Support

J

Teleoperation would likely

be too high risk and

problematic due to

potential latencies, visual

occlusions and reduced

situation awareness.

Therefore control centre

support should be limited

to advice and monitoring

J12.1.5 - No Teleoperation

J

This method may overide or

ignore proximity sensing when

under user control. Without this

so-called Asimov's Laws could

be exploited by assailants to

render the mode completely

ineffective

J12.1.2 - User Ultimate Control

Audiable 'Stand Clear!'

message to warn people in

proximity to the vehicle that it is

moving

S12.1.8 - Audiable Stand Clear

A

Allows those who are able to take

ownership of their risks of

being/remainiing in proximity or

contact with the vehicle. In certain

situations not everyone will be

able to respond appropriately to

the message (drink, drugs,

squashed against the vehicle by

crowd surge)

A12.1.4 - Taking Risk Ownership

Monitoring during the initial

phases of operation. Check

for feature potential and

actual misuse as well as

any confusion surrounding it

on a case by case basis

ramping down to periodic

reviews once it is proven

effective

Sn12.1.1 - In use Monitoring

Human Factors

specialist design

evaluation. Evidence

that the most

suitable design has

been sort

Sn12.1.2 - HF Design

Ethical and legal

assesment of the provision

of the feature an its use for

emergency situations and

possible intentional and

unintentional misuse

Sn12.1.3 - Ethical and Legal

The provision and implementation of

the feature is effective at improving

the personal safety of vehicle

occupants and also meets ethical

and legal concerns

G12.1.9 - Effective, Ethical, and Legal

Human Factors specialist

assessment evaluation.

Evidence that the most

suitable strategy, speed

profile for progression and

message wording/tone

has been sort

Sn12.1.6 - HF Assessment

G12.1.10 - Effective and Safe

Limited supervisied

trials in particular

settings that will provide

confidence that the

technique works and is

safe

Sn12.1.5 - Limited TrialsEvidence from a study of

how pedestrians flow,

move, and can be

interrupted.

Sn12.1.4 - Ped Flow Study

J

Ground clearance

issues mean that

whilst covers may be

added as an additional

precaution, they

probably cannot be

relied upon enough to

provide evidence of

safety

J12.1.6 - Undeveloped

Key

G – Goal

C – Context

A – Assumption

J – Justification


Sn – Solution

Undeveloped



v1.2


Figure 36 : Urban Pilot GSN – Antisocial Behaviour Other Vehicles sub-module (UP12.2)

Driving behaviours from

conventional drivers

G12.2.1 - Other Vehicles

Unreasonably forcing

emergency responses due

to overtaking, cutting in, near

misses, jumping out at

junctions

G12.2.2 - Aggressive Driving

Attempting to force a change in

route or bring to a halt using

one or more vehicles around

the AV

G12.2.4 - Herding and Trapping

Cause a crash to happen

between the AV and another

vehicle

G12.2.5 - Induced CollisionsPeople may be desensitize to the

mistreating of a machine driven

vehicle, either empty or with

passengers. Could be due to

frustation or grevience with AVs or just

the opportunty not to have to potentially

confront another driver

C12.2.1 - Depersonalisation of Driving

Testing of algorithmic limits

and behaviours for future

exploitation

G12.2.3 - Testing for Exploits

Use video footage and auto

number/licence plate recognition as a

deterrent

S12.2.1 - Camera and ANPR Reporting

Treat the same as existing traffic

issues

S12.2.3 - Normal Law EnforcementDetect patterns in repeated

or persistent behaviour and

slow or stop whilst reporting

the incident to a contol centre

or law enforcement

S12.2.2 - Foul Play Detection

Use event logging and traceablilty

measures for accidents to prevent

scapegoating

S12.2.4 - Normal Accident Procedures

Measures are effective enough

to ensure the safe operation

G12.2.6 - Measure are Effective

Progressive rollout and

monitoring of incidents and

general behaviour

Sn12.2.1 - Progressive Rollout

Proving ground tests of particular

scenarios to demonstrate

vehicle behaviour and evidence

the effectiveness of any

countermeasures employed

Sn12.2.2 - Scenerio Track Tests

Key

G – Goal

C – Context


Sn – Solution



v1.2


Figure 37 : Urban Pilot GSN – Antisocial Behaviour General Interference sub-module (UP12.3)

Interference for novelty or

ludicracy

G12.3.3 - Pranks

Car Surfing, hanging on,

hitching, unsolicited towing (of

other vehicles or arbitary items)

G12.3.5 - External Attatchment

Games of chance or limit

testing

G12.3.4 - Playing Chicken

Stone throwing, liquid throwing (paint/oil), tyre

puncturing (nails/debris), sensor jamming

(electronic or physical). Deliberate obstruction by

placing obstacles in the path of the vehicle

G12.3.2 - Vandalism, Disablement and Obstruction


and property damage issues

S12.3.1 - Regular Law Enforcement

Camera feeds. Could be supported

by algorithmic detection

S12.3.2 - Control Centre Montoring

Measures are effective enough to

ensure the safe operation


Review incidents on a case by

case basis and identify any

emerging trends/patterns.

Review periodically

Sn12.3.1 - Incident Monitoring

General interference

G12.3.1 - General

Tipping over the vehicle over or lifting it up

and setting it down in a new location off-

route location such as on private grounds

or so that the wheels are off the ground

using supports or uneven ground

G12.3.6 - Overturning and Misplacement

AV issue related training

and workshops for

personnel involved in

security and law

enforcement

Sn12.3.2 - Updated TrainingFeedback sessions from law

enforcment personnel to

ensure issues are being

noticed and handled

proactively with new design or

operational measures being

introduced as appropriate

Sn12.3.3 - Feedback Sessions

Key

G – Goal

C – Context


Sn – Solution



v1.2


Figure 38 : Urban Pilot GSN – Antisocial Behaviour Agents sub-module (UP12.4)

Use of the vehicle as a

proxy for unwanted activity

G12.4.1 - Agents

Use of the vehicle as a proxy for

surveillence device by stalkers,

snoopers, 'joint casers'. Attach a

'dashcam' or action camera to the

vehicle and send it unoccupied on a

route past a place or person of

interest

G12.4.3 - Remote Covert Surveillence

Use of the vehicle for

transport to facilitate general

criminality

G12.4.2 - General Criminality

Direct use of the vehicle

for terrorism

G12.4.2 - Terrorism

Bombs, incendiary devices,

biological agents

G12.4.5 - Delivery MechanismJamming of road

infrastructure by routing

vehicles through an area.

Might be used in

conjunction with another

act of terrorism to amplify

its effects

G12.4.6 - Road Blocking

Direct misuse of the

Vehicle by occpant(s) to

cause harm

G12.4.4 - Vehicle Misuse

Explotation of override countermeasures to use the

vehicle to cause halm or distruption

G12.4.7 - Misuse of Overrides and Countermeasures

Autonomous 'Scapegoat'. Using

manual control or interventions to

cause harm, then blaming the

system (for causing or allowing it)

when the harm was intended

G12.4.8 - User Induced Accidents

J

Contrained by context

to not have a driver

beyond basic overrides

and countermeasures;

see misuse of

overrides for those



issues

S12.4.5 - Regular Law Enforcement

Use event logging and traceablilty

measures for accidents

S12.4.6 - Normal Accident Procedures

Not including petty

vandalism or

mistreatment to the vehicle

itself

C12.4.1 - Terms of Misuse

Spot checks of

unoccupied vehicles,

particularly when entering

sensitive areas

S12.4.1 - Spot Checks

A

Police stop procedures

implemented. Run-away and

modified vehicles are out of

scope but may need further

consideration for policing

A12.4.1 - Police Stop Procedures

Load sensing, chemical

and fume sensing.

S12.4.3 - Sensing

J

Sensing potentially

difficult, impractical

and could be defeated

by subversives which

may provide a false

sense of security


Referral to Police, DfT and

govermental for review

Sn12.4.1 - Authority Review

The threat is minimised to a

state accepted level

G12.4.9 - Threat is Minimised

Design documents and tests that

demonstrate that

countermeasures have been

designed to limit the deliberate

harm that can be caused as far as

possible to remain useful for the

intended purpose

Sn12.4.2 - Countermeasure Limits

G12.4.10 - Misuse Acceptably Low

Tests and demonstrations of

datalogging, event

reconstruction, that show

deliberate misuse can be

identified

Sn12.4.3 - Misuse Identification

Incident monitoring to

support the chosen method

(s) remain effective. Periodic

review of procedures to react

to useage behavioural

changes

Sn12.4.4 - In Use Monitoring

Where vehicles a part of a

managed fleet, be able to

detect anomalous

patterns. Also require

cooperation between fleet

operations

S12.4.3 - Fleet Monitoring

A

Issues of personal privacy

arise when considering

the route tracking of

privately owned vehicles.

Where vehicles are able

to run unoccuppied, it may

become a 'necessary evil'

that they are tracked

A12.4.2 - Private Vehicles

S12.4.4 - Useage Tracking

J

A difficult trade off

between civil liberties

and crime prevention


Limit access to sensitive

areas of unoccupied

vehicles. (e.g. Require

manual barrier operation)

S12.4.2 - Limit Access

J

Likely to be easy to

defeat using an

external stooge or by a

passenger jumping

out at the appropriate

stage to defeat the

prevention mechanism


Key

G – Goal

C – Context

A – Assumption

J – Justification


Sn – Solution

Undeveloped


Summary and Concluding Thoughts

v1.2


7 Summary and Concluding Thoughts

7.1 General

It is hoped that this report and the GSN approach will assist with the thought process of understanding the

complexities surrounding CAV development and subsequent rollout. There are many challenging situations

which arise day to day when driving on the roads which also need to be addressed for vehicles if they are

to be operated autonomously. The exercise of strategy selection (pruning) has been deliberately left as an

exercise to the reader, to apply ALARP principles. Despite this, in many cases it appears that when the

ALARP point has been reached the residual level of risk may still be far too high without resorting to

infrastructure support. This is however an issue of what levels of residual risk are acceptable, which is a

question for governments and society to answer. A common theme is the need for a robust and resilient

digital mapping and vehicle localisation system, without which road casualty rates will be dependent upon

image processing and object recognition techniques.

7.2 Roads and Regulation

The following are concluding thoughts and suggestions in relation to roads and regulation:

• It is envisaged that some road types will be challenging for fully automated vehicles for many years

to come. Narrow roads, two-way single carriageway high speed rural roads, complex junctions and

areas with many road user types could be amongst the most challenging. Restricted use (e.g. geo-

fencing) may be required to allow the benefits of automation to be realised more quickly along

roads which are more manageable for AVs.

• Type Approval for AVs could be focussed on conformance with particular expected vehicle

behaviours (e.g. overtaking and negotiating junctions) that are currently left to the discretion and

due diligence of human drivers.

• Consideration should be given to a national mapping infrastructure. This could be licensed to

private sector providers in a similar manner to a mobile phone network, but would give a single

source of the truth. OEM and technology providers could layer their own proprietary features on

top on a national base map to provide additional brand defining functionality.

• Consider developing a road and zone suitability assessment procedure for AVs alongside a

classification system for which vehicles could be certified as being capable of automated operation

against a particular road or zone class.

7.3 Vehicles and Technology

The following are concluding thoughts and suggestions in relation to the vehicles and associated

technologies:

• It is a known human factors trait that people are poor at supervising automation, especially when

it infrequently fails. The idea of the handover of a moving vehicle for general drivers is gradually

being accepted as a bad idea despite it being a convenient solution from the point of view of

system development and evolution as well as confidence building in the technology.

• From this, it seems that a step change from partial to full automation is needed rather than a

gradual evolution which relies on a driver to intervene when the system fails.

Summary and Concluding Thoughts

v1.2


• Weaknesses in processes associated with automated driving, such as estimation, interpretation

and prediction, can have consequences comparable to those of hardware and software failures in

traditional safety of automation, and the seriousness of those weaknesses should not be

underestimated. This is not currently addressed by ISO 26262.

• Sensor fusion is often only as good as the weakest sensing method and having a mixed bag of

sensors does not guarantee sufficient coverage for all situations.

• Localisation systems may fuse several data sources to plug coverage gaps (where the vehicle

cannot locate itself - GPS/GNSS denied areas or a lack of local landmark features). These gaps and

exactly how they will be managed for all times and locations will need to be understood better.

For highly automated driving determinism is preferable to a carousel of weaker solutions that may

be switched in with the hope that one will always be available. Heterogeneous redundancy (using

multiple location data sources) does not always provide more resilience, and may serve to falsely

increase confidence though obfuscation of its failure modes

• The connectivity and automation technical communities need to work closely together and

converge their efforts to avoid a connectivity roll-out which only serves to provide driver assistive

information and is not of any real use to providing an infrastructure for failsafe automation.

• A system engineering approach to vehicles and infrastructure is needed, rather than stand-alone

vehicle or infrastructure centric approaches

7.4 Standards, Ethics, and Safety Case

The following are concluding thoughts in relation to standards, ethics and safety case:

• Standards normally follow practice, but ISO 26262 was a slight exception in that practice in the

industry was to some extent formed from it.

• Current standards cover fault-failures but not system insufficiencies.

• There is a need to address the standards gap related to insufficiencies and safety of the intended

functionality.

• There needs to be a conceptual model of the operation and safety case for automated vehicles to

form the consensus of practice from which the standards gap can be filled, rather than

speculatively forming standards in the hope they will be adopted as the de facto approach. This

could greatly assist in the forward progress with the development and roll-out of CAVs by breaking

the competitive stalemate that has arisen from the expectation that a fully functional standalone

CAV platform will just emerge from one of the technology providers.

• There is a paradox between traditional approaches to the design of hardware and software

intended for preventing hazards high risk situations, and the design complexity required to cope

with the chaotic random events of real-world driving. This arises from removing the driver as a fall

back and arbiter to which responsibility and liability has been previously placed.

• Current solutions do not appear conceptually commensurate with the inherent risks both from a

hardware and a software perspective and are not currently implementable against current fault

failure standards such as ISO 26262 before even considering algorithmic and sensing

insufficiencies.

• An industry consensus or common understanding of the general safety case would help to focus

design and vice versa since having some concept of the design is required to base the safety case

v1.2


upon. Currently this approach is being resisted as it is seen as being anti-competitive despite the

fact that the industry has a long history of eventually converging around common designs.

• There is a need for protection of data integrity across domains when relied upon by vehicles for

safety.

• Consideration of the residual risks when an ALARP or SFAIRP strategy has been reached is needed

and whether or not these risks are acceptable, and what else could be done if not.

• The GSN provided here could be evolved and unused strategies pruned. Preferred approaches

could be further developed.

v1.2


Transport Systems Catapult

The Pinnacle, 170 Midsummer Boulevard

Milton Keynes MK9 1BP

Tel: 01908 359 999

www.ts.catapult.org.uk

linkedin.com/company/transport-systems-catapult

Twitter: @TSCatapult

Taxonomy of Scenarios for Automated Driving - Amazon S3 · Taxonomy of Scenarios for Automated...

Documents

Transcript of Taxonomy of Scenarios for Automated Driving - Amazon S3 · Taxonomy of Scenarios for Automated...