Towards a Framework for Safety Assurance of Autonomous Systems John McDermid, Yan Jia, Ibrahim Habli Department of Computer Science, University of York, UK john.mcdermid, yan.jia, ibrahim.habli @york.ac.uk Abstract • Some of the challenges of analysing shared autonomy. These issues underpin the proposed framework; they are il- Autonomous systems have the potential to provide lustrated in section 2 which considers some AS accidents. great benefit to society. However, they also pose AS used in safety-related situations should be subject to problems for safety assurance, whether fully auton- safety processes. Previous analysis of quantitative risk anal- omous or remotely operated (semi-autonomous). ysis (QRA) [Rae et al 2014] identified limitations of classical This paper discusses the challenges of safety assur- safety processes, many of which are relevant to AS. Section ance of autonomous systems and proposes a novel 3 draws out key issues, considering the impact on both assur- framework for safety assurance that, inter alia, uses ance and regulation. It also reviews the literature on AI safety machine learning to provide evidence for a system seeking to show a correlation with the QRA limitations. safety case and thus enables the safety case to be up- Section 4 outlines the top-level of the framework and iden- dated dynamically as system behaviour evolves. tifies some of the work that will underpin (flesh out) the framework. The framework seeks to address some of the lim- 1 Introduction itations in safety processes identified in the analysis of QRA. This paper addresses the safety of autonomous systems (AS). The major novelty of the framework is that it includes the use It is intended to cover the spectrum from those that are semi- of ML in safety assessment as well as its role in the AS itself. autonomous (remotely controlled or operated) through to As the framework is new, it has not yet been applied to an those that operate largely free of human oversight. Often AS AS. However, a related framework, which has informed our use artificial intelligence (AI), including machine learning ideas, has been applied in complex healthcare settings, see (ML), as a key implementation mechanism. The paper relates Section 5. Using such an example also shows how the frame- to the System Assurance and Certification and the AI Safety work might be used for AI safety more generally, not just for Foundations focus areas of the AI Safety Landscape. It pro- safety of AS. poses a novel safety assurance framework. Sections 6 discusses related work and future plans; Section 7 presents conclusions. 1.1 Spectrum of Autonomy The paper considers some apparently disparate concepts. In the authors’ view AS are best thought of as systems where The ambition is to draw these concepts together to propose a decisions that would otherwise have been taken by humans framework that can address the wide range of factors that in- are allocated to machines. In practice, many systems have fluence safety and assurance of AS, not just AI. As the ideas ‘shared autonomy’ where operators can monitor and poten- are evolving the paper shows a ‘direction of travel’, not a fin- tially over-ride the system’s decisions and actions. Often the ished product; it is hoped that this will help stimulate debate. function (decision) allocation between humans and AS can vary over time. In some sectors, e.g. automotive, the spec- 2 Motivating Examples trum is codified into ‘levels’ of autonomy. However, diverse Examples are presented which illustrate the problems of the sectors use different definitions of levels, so we choose here use of AI/ML, and shared autonomy, respectively. The intent just to refer to a spectrum; ultimately our proposed frame- is primarily to identify the issues that need to be addressed in work is intended to address the whole spectrum of autonomy. producing a safety assurance framework for AS. 1.2 Scope and Ambition 2.1 Autonomous Road Vehicles Producing a complete framework for assuring AS, or even the There have been several fatal accidents with autonomous AI elements of such systems, is a major endeavour. The scope road vehicles (AVs). We consider two accidents which can in this paper is more limited and we address: be viewed as illustrating some of the issues with AI and ML • Some of the challenges of use of AI and ML in AS, (as image analysis necessarily uses ML), although this is not particularly focusing on training and testing; fully covered in the accident reports. A fatal accident occurred in May 2016 when a Tesla on autopilot impacted a truck (semi-trailer) near Williston Flor- ida. The NTSB’s analysis of probable cause refers to the driver of the truck failing to yield, and to the Tesla driver’s ‘inattention due to over-reliance on vehicle automation’ [NTSB 2017]. However, the report also says: ‘the Tesla’s au- tomated vehicle control system was not designed to, and did not, identify the truck crossing the car’s path or recognize the impending crash’; if it had recognised the obstacle in its path the Tesla could have applied emergency braking. This shows the challenge of training and testing image analysis systems for operation in an open environment but doesn’t give any specific information on the issues for the ML processes. Figure 1. Abstract Model of WK Accident Causation The NTSB preliminary report on the Uber accident in Tempe Arizona in March 2018 [NTSB 2018] gives a more The design model used, including for safety analysis, was detailed account of the events leading to the accident than is not an accurate predictor of the actual behaviour of the sys- present in the Tesla analysis. The pedestrian was first ob- tem (in its operational environment). The ground crew train- served about 6 seconds prior to the accident. The report says: ing and documentation did not help them to understand the ‘the self-driving system software classified the pedestrian as actual system behaviour, including WCAs. Finally, workload an unknown object, as a vehicle, and then as a bicycle with had a significant impact on the operators’ ability to observe varying expectations of future travel path. At 1.3 seconds be- the state of the system and to control it. There is a dissonance fore impact, the self-driving system determined that an emer- between the three sub-models in Figure 1 which is redolent gency braking maneuver [sic] was needed’. The Uber system of the distinctions made between ‘work as imagined’ and relied on the driver for emergency braking and was not in- ‘work as done’ [Hollnagel et al 2006]. This dissonance is only tended to initiate an emergency stop. likely to get worse for systems that learn in operation. This example illustrates more fully the problems for ML: how to reliably detect and classify objects in the environment 3 Safety and Assurance Challenges for AS whilst avoiding ‘false alerts’ that would prevent expeditious By assurance we mean justified confidence or certainty in a progress? It also illustrates the shared autonomy problem, but system’s capabilities, including its safety. The motiving ex- this is shown more fully below. amples have given some practical illustrations of why assur- ing safety of AS is challenging. This section considers these 2.2 Unmanned Air Systems challenges more systematically drawing together three differ- The United Kingdom (UK) Army uses an Unmanned Air ent perspectives. First, it considers ‘classical’ safety pro- System (UAS) known as Watchkeeper (WK) for reconnais- cesses, but focusing on their limitations. Second, it considers sance. WK is operated and supported by a ground crew at a the ‘AI perspective’ on safety. Third, it presents a perspective Ground Control Station (GCS) but some functions are auton- on assurance challenges from a programme addressing assur- omous, e.g. the ability to execute a go-around (rather than ance and regulation of AS, including their use of AI/ML. landing). WK does not use AI or ML but it is a good example of the shared autonomy problem. 3.1 Safety Processes and their Limitations WK has suffered five accidents to date; a far higher loss The principles of classical safety processes apply to AS. It is rate than the safety analysis predicted [Wilby 2019]. The UK necessary to identify hazards, to assess (safety) risks associ- Defence Safety Authority (DSA) report on the fourth WK ated with the AS, and to change the design (or operational crash [DSA 2019] draws out three ‘themes’ from all five ac- profile) if the risks are too high, in order to make the system cidents (the fifth is still being investigated but the DSA has acceptably safe. In this paper we assume that the safety pro- visibility of the investigation). The themes highlighted are: cess results in the production of a safety case – a justification 1. The incomplete understanding of the full system, and (or argument), supported by evidence, that the system is safe how sub-systems integrate; to operate in its intended context of use. 2. The need to improve collection and analysis of data; A systematic review of Quantitative Risk Analysis (QRA) 3. Ground crew and engineer workload. [Rae et al 2014] showed that the quantitative results are nor- For example, in the third area, the report cites the high rate of mally not accurate. Safety analysis is not just quantitative, but warnings, cautions and advisory (WCA) notifications creat- the problems identified affect the validity of all aspects of ing a high workload. Further, the ground crew rely on their safety analysis, whether or not the results are quantified [Rae collective knowledge to understand the situation and how to et al 2014]. The paper proposed a five-level hierarchy for im- respond, e.g. to interpret WCAs rather than referring to doc- proving QRA, which is also relevant to AS: umentation (paper or electronic). Thus, based on our reading 1. Unrepeatable, e.g. analysis relies on undocumented of the reports and from discussions with the manufacturers assumptions; [Wilby 2019], we propose the abstract model of accident cau- 2. Invalid, e.g. for WK, design models were not accurate sation set out in Figure 1. predictors of operational behaviour; 3. Valid but inaccurate, e.g. inadequate treatment of un- 3.3 Assurance and Regulation certainty such as in object classification; The Lloyd’s Register Foundation review of robotics and AS 4. Accurate but challengeable, e.g. insufficient scientific (RAS) identified challenges (they used the term ‘white knowledge for parts of the analysis (this is likely to be spaces’) in assurance and regulation of RAS [LRF 2016]. The a particular issue for AS using ML); Assuring Autonomy International Programme that was set up 5. Ideal (which the paper views as unattainable). in response to the above review has amplified on these issues The intention is that flaws at level 1 need to be corrected and identified Critical Barriers to Assurance and Regulation before a safety analysis can move to level 2, and so on. Flaws (CBARs) [AAIP 2018]. CBARs are characterized as prob- identified in [Rae et al 2014] are referred to here as §x.y lems that must be solved otherwise there is a risk that: meaning flaw y at level x, e.g. §2.3 is ‘mismatch between the 1. Unsafe systems are deployed, or risk assessment and reality’ – a key point drawn out in our 2. Safe systems cannot be deployed. motivating WK example. The level 4 flaws are of particular The distinction between these two cases rests on the regu- relevance to AS – in general we do not have a good scientific latory regime; a permissive regulatory regime which allows basis for safety assessment of ML. [Rae et al 2014] identify systems to be deployed in the absence of contrary evidence is other flaws that motivate our framework, and we discuss prone to the former risk (arguably this is what happened in some of these in Section 4. the case of the AV accidents outlined above); a restrictive re- 3.2 Challenges of AI Safety gime is prone to the latter which might inhibit the beneficial use of RAS (hereinafter AS for brevity). The AI community have recently produced a number of pa- CBARs are intended to highlight key issues in the assur- pers on the problems of ‘AI safety’ e.g. [Domingos 2012], ance and regulation of AS, with the aim of focusing research [Feige 2019]. It should be noted here that there is a disso- on these issues to expedite safe deployment of AS. The nance between the use of the term ‘safety’ in the AI and safety CBARs are intended to apply across different application do- engineering communities. The latter focus on injury or death mains, e.g. UAS or medical devices. Two CBARs relevant to to humans; the former takes a wider definition that encom- this paper are (simplified and merged from [AAIP 2018]): passes robustness, privacy and security, and they tend to fo- 1. Monitoring and handover – how can it be ensured and cus more on mechanisms for producing ‘unsafe’ results assured that operators retain sufficient levels of atten- whereas safety engineers are more concerned about effects. tion and concentration to handle problems that arise? Fortunately, these different perspectives are complementary 2. Training and Testing – how can it be shown that the and safety engineers can usefully consider ‘AI safety’ con- training and test sets used in ML give enough cover- cerns as potential causes of a hazard. age of the environment to provide sufficient evidence One of the more influential papers [Amodei et al 2016] to allow controlled use of the AS? identifies ‘concrete problems in AI’. The paper is largely fo- All three accidents discussed in Section 2 illustrate the cused on reinforcement learning; the problems they identify monitoring and handover CBAR; the AV accidents illustrate can be rephrased as follows, to make them more general: the second CBAR. 1. Avoiding negative side effects – ensuring that the be- haviour meets safety constraints; 2. Avoiding reward hacking – ensuring that the behav- 4 The Proposed Framework iour doesn’t get a high reward by ‘cheating’ and thus The framework proposed here is intended to provide a basis avoiding the benefit that was sought; for assurance and regulation of AS, taking into account the 3. Scalable oversight – this concerns the ability of the use of AI/ML in their development. Although safety princi- human to interact with the system both to monitor it, ples apply to AS the analysis can be difficult, especially and to respond to requests for confirmation of deci- where the behaviour of the system can evolve in operation sions prior to actions being taken; (e.g. due to ML). The core difficulty is that traditional safety 4. Safe exploration – if the system can try out new things processes assume that safety can be assessed prior to deploy- (new strategies) how can negative outcomes be ment and the assessment remains largely valid through life. avoided if these are circumstances that have not been The framework therefore includes continued and proactive considered hitherto; assessment in operation – in contrast to current safety man- 5. Robustness to distributional shift – how the system agement that tends only to update safety assessments in re- adapts to changes in the operational environment. sponse to problems or accidents. It draws on Hollnagel’s Problem 3 arises for WK even though it does not use AI. ‘work as imagined’ and work as done’, but re-setting these as The two AV accidents illustrate both problems 1 and 3 (alt- the ‘world as imagined’ (as we have to consider the system hough there are issues of psychology here too). The Tempe and its environment) and the ‘world as observed’ (or the ‘data Uber accident seems to reflect problem 4. There are real- world’) reflecting the need to analyse operational data to un- world examples of both problems 2 and 5, e.g., ship classifi- derstand and control the dissonances identified above. cation algorithms that work in the Baltic but not near the equator due to differences in the angle of elevation of the sun, 4.1 Framework Overview typical wave patterns, etc. The framework has four major elements which are conceptu- ally distinct, although they physically overlap to some extent: Figure 2. Top-level of the Proposed Safety Assurance Framework • The ‘real world’ contains the AS in its operational • Uncertainty – the inability to model all the likely environment; variations in the environment, or the distribution of • The ‘world as imagined’ contains design and simu- possibilities, due to ‘real world’ complexity, [§3.3 lation models, and the results of safety analysis ‘insufficient characterization of uncertainty’]. based on those models; These factors (and more) contribute to the mismatch be- • The ‘world as observed’ contains the operational tween the real and imagined worlds, and thus limit the fidelity data, e.g. images produced by sensors, and the re- (predictive accuracy) of the safety analyses. The training data sults of ML analysis of the operational data; ‘gap’ clearly links to the ‘training and testing’ CBAR. • A safety case, initially reflecting just the ‘world as The ‘world as observed’ is also affected by ‘gaps’ as imagined’ later updated to respond to the ‘world as shown in Figure 2, which represent different sorts of mis- observed’, reducing the gaps between the safety match with the ‘real world’. These include: case and reality. • Sensing – sensor sets, e.g. lidars and cameras, will The ‘real world’ environment includes both the physical have limited capabilities and are affected by the en- infrastructure, e.g. roads, and people, including operators, vironment, e.g. rain, dust clouds, etc.; passengers, etc., as well as the AS. This is the ‘ground truth’. • Algorithmic limitations – characteristics of algo- Design produces models of the system and environment, rithms, e.g. balancing false positives against false including simulations both to define what is to be produced, negatives, or sensor data fusion not always selecting and to analyse it. In the framework, safety analysis including the best combination of data sources to use; hazard analysis and the identification of risk mitigations are • Failure conditions – hardware can fail, and this can key elements of the ‘world as imagined’, but this is where affect behaviour (but it should be addressed by con- model mismatches (dissonances) can start to arise. ventional safety processes); There are ‘gaps’ between the ‘real world’ and the ‘world • Human/team performance – limitations in human as imagined’, see Figure 2, that are challenges for safety anal- cognition and capability, allowing for factors that ysis. The gaps identified in Figure 2 (with example mapping shape human performance, e.g. the high level of to flaws in [Rae et al 2014]) include: WCAs that affected the WK accidents; • Assumptions – what is taken as a ‘given’, about the • Resource limitations – many AI/ML algorithms are system or environment, e.g. driver will be able to non-deterministic and, for example, it is possible for intervene and apply emergency braking [§2.3 ‘mis- object classification algorithms to ‘lose’ objects if match between the risk assessment and reality’]; they run out of time between video frames (this is • Framing (scoping) – deciding what aspects of the viewed as distinct from algorithmic limitations if the ‘real world’ should be considered, and which do algorithm would not ‘lose’ the objects given suffi- not, e.g. in determining what objects might need to cient processing resources). be classified by an AV vision system, such as pe- The human/team performance ‘gap’ relates to the monitor- destrians pushing bicycles [§2.2 ‘Major omissions ing and handover CBAR. in the analysis’]; The sensor and algorithmic issues are not always disjoint • Model fidelity – precision and accuracy of the mod- and, for example, the failure of the Tesla to identify the semi- els used, including simulations, e.g. point mass ap- trailer in the Florida accident, is likely to have been due to a proximations to the dynamics of AVs [§2.4a ‘Mod- combination of such limitations. els are used outside their valid scope’]; As with the mismatches between the ‘real world’ and • Training data – limitations of the data used to train ‘world as imagined’, these gaps are illustrative, not exhaus- the ML in AS, e.g. biases in data sets used for pe- tive. Again, these reflect problems identified by [Rae et al destrian detection, so that some ethnic groups are 2014], viz: Sensing maps to §3.1 ‘insufficient rigour in se- misclassified [§2.8 ‘failure to report limitations’]; lecting source data’ and Algorithmic limitations maps to §3.2 ‘incorrect processing of data’, albeit extending these catego- the potential problem of distributional shift between ries to the operational system, not just the safety analysis. the simulator and AV; Note that gaps can also arise in the ‘world as observed’ from • The rationale for choosing factors that shape the the ‘work as imagined’ shown as ‘inherited gaps’ in Figure 2. learning process including selection of training and The most novel part of the framework is the ML analysis test data sets, and ‘hyperparameters’. in the ‘world as observed’. Safety analysis on the ‘world as The ‘hyperparameters’ in model learning are important as imagined’ is hypothetical – it is based on design models and the models learnt are dependent on these values. For exam- on an imperfect understanding of the environment. The WK ple, Bayesian Network (BN) structure learning can be used to example shows clearly that such mismatches are a serious identify correlations between elements in the training data. problem and form significant contributions to the accidents. The relevant hyperparameter is Equivalent Sample Size Systems employing AI and ML are data rich, and this (ESS) which is used to guide the learning process when BDeu opens up the possibility of using ML on the operational data (Bayesian Dirichlet equivalent uniform) score is used for the both to understand the factors that actually influence safe be- structure learning. In general, increasing ESS leads to learn- haviour, and to validate or to inform refinement of, the safety ing more links in the structure, but the number of links does analyses. The rate at which operational data is produced will not necessarily increase monotonically. The arguments will exceed human capability for analysis in real-time, but ML of- be domain specific, e.g. for a data set with a skewed distribu- fers the opportunity to identify the critical information in the tion, which is very likely with AVs, for example, a smaller data. In this way the initial safety case would reflect analysis ESS value is preferred [Steck 2012]. of the ‘world as imagined’, but then would be updated with The Assuring Autonomy International Programme is de- ML analysis of the ‘world as observed’. Such an approach veloping a Body of Knowledge (BoK) which includes tem- would allow the safety case to stay in (closer) alignment with plate assurance arguments to address these issues [AAIP the system behaviour, which has been referred to as a dy- 2019]. The BoK contains guidance on the structure of assur- namic safety case [Denney et al 2015], [Calinescu et al 2018]. ance arguments and the criteria for evidence and will evolve The framework also supports feedback, enabling the safety to provide more details. e.g. using different search algorithms analysis to be improved based on the ‘world as observed’, for learning BN structures to improve confidence. and to improve the data collection and ML analysis. 4.3 Example using ML for Safety Analysis 4.2 Assurance of ML in the Framework The development of the framework presented here has been The safety case needs to address explicitly each of the ‘gaps’ influenced by parallel work on safety of medication manage- identified in Figure 2 and demonstrate that the impact on the ment which has had to address very similar issues of mis- behaviour (safety) of the AS is small enough to permit initial match between the ‘world as imagined’ and ‘world as ob- operations (see the discussion of regulatory issues below). served’. The following illustrative example focuses on the Figure 2 is not rich enough to show all the issues relating to ‘ML analysis’ in the ‘world as observed, as this is the most ML in AS; these will require a more detailed model. The As- novel part of the framework. suring Autonomy International Programme is working on The example is of a Health IT (HIT) system rather than an such models [Ashmore et al 2019]. For simplicity we draw AS [Jia 2019]; as mentioned above, this example is chosen as out only a small number of issues highlighted in their ML it best illustrates the framework, in the absence of an applica- process model relevant to the ‘training and testing’ CBAR. tion to AS. In the HIT work, the mapping to the framework The safety case needs to provide arguments and evidence is as follows: for the coverage of the training and testing data, noting that • Real world – hospital environment, including HIT the coverage criteria should be informed by the safety pro- systems; cess. Thus, for an AV, the focus should be on coverage of • World as imagined – healthcare pathway model re- those driving situations which are hazardous, e.g. junctions, lated to post-operative care of patients following oe- driving into low sun, and not ‘undemanding’ situations such sophagectomy, and safety analysis using Software as quiet dual carriageways (divided highways). However, it Hazard Analysis and Resolution in Design (SHARD) is unlikely (undesirable) that good coverage of near-accident [Pumfrey 1999] based on the healthcare pathway; data will be achieved using real world data – it is too rare, and • World as observed – real data from the HIT system, too dangerous to collect – thus collection must be augmented and BN structure learning to explore the correlations by simulation data to get good coverage of the operational between the different factors identified in the safety design domain (ODD), from a safety perspective. Thus, the analysis, representing hazards, causes and their ef- argument should address a number of issues: fects; this enables the safety analysis to be validated in • The coverage of the ODD in the data used for train- the real world. ing and testing, justifying the ‘skew’ in the data to The structure learnt showed new patterns in the ways that get coverage of ‘demanding’ situations based on the nurses carry out their work during post-operative care follow- assessment from the safety analysis, e.g. vehicle ing oesophagectomy which was not expected as it was neither cut-in and emergency braking to avoid pedestrians; apparent in the pathway model nor in the safety analysis. This • The choice between real-world and simulation data, can be characterized as ‘flaw’ §2.3 [Rae et al 2014] ‘mis- again based on risk assessment, and dealing with match between the risk assessment and reality’. BN parameter learning was used to quantify the effects of In some ways, this is what AS developers are doing now, e.g. different causes and controls on the associated hazard in or- progressively expanding the ODDs of AVs. Doing this ‘for- der to understand their significance, enabling the introduction mally’ through a regulatory process would be a substantial of the potential hazard controls to be prioritized. culture shift, in many domains, not least for the regulators. 4.4 Regulation based on the Framework 5 Discussion and Future Work As noted above, regulatory processes assume that system ap- The ideas presented here are evolving and have their roots in proval is essentially static, only updated for major events, e.g. the earlier analysis of QRA and considerations of how safety significant design changes or accidents. Where AS evolve engineering can ‘catch up’ with design engineering [McDer- their capability over time, e.g. using ML, then a more evolu- mid 2017]. They were crystalized by discussions of the WK tionary approach is needed, with two primary phases. accidents. The aspiration is to use ML to understand and re- First, initial operation of the AS should be based on safety duce the ‘gaps’ identified in Figure 2. Our initial work on HIT analysis of the ‘world as imagined’. The decision to approve is encouraging, but the ideas need to be applied to AS. There the system must be based on an assessment of risk that will is work using ML on operational data, e.g. for assessing reflect the arguments that the ‘gaps’ identified in Figure 2 drowsiness of car drivers [Schwarz et al 2019]. However, we have been adequately controlled. For AVs this amounts to de- believe that use of ML on operational data to update safety ciding whether or not the use of the AV in an initial ODD cases is a unique perspective, but one that we hope might help carries an acceptable risk. This will, for example, include to build bridges between the safety and AI communities. consideration of sufficiency of the training and augmentation Also, there is a need to revise safety analysis processes to data in the specified ODD, as outlined above. reflect the characteristics of AS and ML, for example chang- Second, operation of the system will provide data, which ing the notion of controllability used in risk assessment for is then analysed using ML, to either confirm the safety anal- road vehicles as they become more autonomous [Habli et al ysis in the ‘world as imagined’ or to identify areas in which 2016]. There is other work in this area, and several authors the safety analysis is not consistent with the ‘world as ob- have made use of Leveson’s STAMP/STPA or referred to its served’ (or the ‘real world’) in a way that is safety significant. utility [NHTSA 2018], [NASA 2018]. STAMP/ STPA re- The operational data would enable identification of structural flects a control systems perspective which is highly appropri- weaknesses or ‘flaws’ in the safety analysis, such as identi- ate for AS, and some aspects of the models might help ad- fied in [Rae et al 2014]. For example, if using BN structure dress the ‘flaws’ in QRA [Rae et al 2014], however it is not learning, the learnt structures may show correlations of causal clear that the approach helps particularly with the ‘gaps’ iden- factors of hazards not reflected in the safety analysis, which tified in Figure 2. Thus, we believe that more will need to be is an example of §2.2 ‘Major omissions in the analysis’. Iden- done to produce an effective safety analysis process for the tifying such a problem should prompt review and, if appro- ‘world as imagined’, and thus improve the safety analysis of priate, revision to the system design, its operation, e.g. limi- AS. There is relevant work for AVs, including on Safety of tations to ODDs for AVs, and update of the safety analysis to the Intended Function and on a ‘standard for safety for the reflect a better understanding of the ‘real world’, etc. evaluation of autonomous products’ by the Underwriters La- In the WK example this might involve an analysis of boratory (UL), known as UL 4600 [Koopman 2019]. UL ground crew workload (using ML) and a redesign of WK (or 4600 will explicitly address some of the requirements on more likely its support systems, e.g. the GCS) to reduce safety cases for AVs employing AI and ML discussed above; workload, with an associated update to the safety analysis and a public draft of UL 4600 should be available during 2019. the safety case. Put another way, the ML analysis in the We think that the notion of ‘gaps’ is helpful in considering ‘world as observed’ enables organisations to learn from ex- the wider issues of AS safety. Moving decision-making to an perience, and to update their approach to safety, rather than AS can create a ‘responsibility gap’ where it is unclear who the safety analysis being ‘open loop’ [McDermid 2017]. is responsible for an action (in an ethical sense) [Porter et al Of course, the analysis of the ‘world as observed’ may 2019], and there may be no-one responsible in a legal sense show that the risk is lower than predicted and that there is a (e.g. Arizona determined that Uber did not have a case to an- ‘safety margin’. In principle, this can be used to justify ex- swer for the Tempe fatality). We see the possibility of devel- tending the use of the AS – perhaps expanding the ODD for oping a new and rich socio-technical ‘theory of safety’ that an AV, or expanding the fleet size for a UAS, or allowing draws together multiple disciplines, including AI, system UAS to fly in more congested airspace. safety engineering, law and ethics. A key part of this will be ML can be applied to data from the AS in (near) real-time reconciling system safety with AI safety – combining system so, in principle, the safety case can be updated continuously. safety’s view of the harm to humans from AS with the under- However, unless regulatory approval can be automated so it standing from the AI safety community of what might go can track the evolution of the evidence base, as might be done wrong in AI and ML. using run-time certification [Rushby 2008], it is likely that human regulators would approve changes to usage in ‘incre- 6 Conclusions ments’ from time to time. This could be done where the evi- dence produced by ML analysis in the ‘world as observed’ The introduction of AS has the possibility of providing sig- enables the gaps affecting confidence in the AS to be reduced. nificant benefits to society, for example in social care and in reducing fatalities on the road. However, there are also fun- [Habli et al 2016] Monkhouse, H., Habli, I. and McDermid, damental challenges to safety and regulatory processes as the J., 2015, September. The Notion of Controllability in an WK example, and accidents and incidents with AVs, show. autonmous vehicle context. In CARS 2015-Critical Auto- The framework presented here reflects both empirical un- motive applications: Robustness & Safety. derstanding of problems with particular AS, and a much more [Hollnagel et al 2006] Hollnagel, E., Woods, D.D. and thorough analysis of weaknesses of safety processes in gen- Leveson, N., 2006. Resilience engineering: Concepts and eral, and QRA in particular. However, it is abstract, and more precepts. Ashgate Publishing, Ltd. detail is needed; the Assuring Autonomy International Pro- gramme BoK [AAIP 2019] and standards such as UL 4600 [Jia 2019] Jia, Y., 2019, Improving medication safety using should provide some of the necessary underpinning. machine learning. AIME 2019, Poland, Springer, In press. There has been an initial validation of the framework on a [Koopman 2019] Koopman, P., 2019. Private communica- healthcare example. It is hoped that the proposed framework tion. will help to unify perspectives on AI safety and contribute to [LRF 2016] https://www.lrfoundation.org.uk/en/news/fore- the development of the AI Safety Landscape. sight-review-of-robotics-and-autonomous-systems/ (ac- cessed May 2019) Acknowledgements [McDermid 2017] McDermid, J., Playing Catch–Up: The This work was supported by the Assuring Autonomy Interna- Fate of Safety Engineering? Developments in Systems tional Programme. Safety Engineering, Safety-Critical Systems Club, M Par- son T P Kelly (Eds), 2017. References [NASA 2018] Alves, E.E., Bhatt, D., Hall, B., Driscoll, K., [AAIP 2018] Assuring Autonomy International Programme, Murugesan, A. and Rushby, J., 2018. Considerations in Critical Barriers to Assurance and Regulation. Assuring Safety of Increasingly Autonomous Systems. https://www.york.ac.uk/assuring-autonomy/projects/bar- [NHTSA 2018] National Highway Traffic Safety Admin- riers-to-assurance/ (accessed May 2019) istration, Functional Safety of an Automated Lane Cen- [AAIP 2019] Assuring Autonomy International Programme, tering System, DOT HS 812 573, 2018. Body of Knowledge. https://www.york.ac.uk/assuring- [NTSB 2017] National Transportation Safety Board, 2017. autonomy/body-of-knowledge/ (accessed May 2019) Collision Between a Car Operating With Automated Ve- [Amodei et al 2016] Amodei, D., Olah, C., Steinhardt, J., hicle Control Systems and a Tractor-Semitrailer Truck Christiano, P.,, Schulman, P., and Mané, D., Concrete Near Williston, Florida May 7, 2016, NTSB/HAR-17/02 Problems in AI Safety, arXiv.org, 2016. [NTSB 2018] National Transportation Safety Board, 2018, [Ashmore et al 2019] Ashmore R., Calinescu, R., Paterson, Preliminary Highway Report, HWY18MH010. C., Assuring the Machine Learning Lifecycle: Desiderata, [Porter et al 2018] Porter, Z., Habli, I., Monkhouse, H., & Methods, and Challenges, arXiv preprint, arXiv: Bragg, J., 2018. The moral responsibility gap and the in- 1905.04223. creasing autonomy of systems. In International Confer- [Calinescu et al 2018] Calinescu, R., Weyns, D., Gerasimou, ence on Computer Safety, Reliability, and Security (pp. S., Iftikhar, M.U., Habli, I. and Kelly, T., 2018. Engineer- 487-493). Springer. ing trustworthy self-adaptive software with dynamic as- [Pumfrey 1999] Pumfrey, D.J., 1999. The principled design surance cases. IEEE Transactions on Software Engineer- of computer system safety analyses (Doctoral disserta- ing, 44(11), pp.1039-1069. tion, University of York). [Denney et al 2015] Denney, E., Pai, G. and Habli, I., 2015, [Rae et al 2014] Rae, A., Alexander, R. and McDermid, J., May. Dynamic safety cases for through-life safety assur- 2014. Fixing the cracks in the crystal ball: a maturity ance. In 2015 IEEE/ACM 37th IEEE International Con- model for quantitative risk assessment. Reliability Engi- ference on Software Engineering (Vol. 2, pp. 587-590). neering & System Safety, 125, pp.67-81. IEEE. [Rushby 2008] Rushby, J., 2008, March. Runtime certifica- [Domingos 2012] Domingos, P., 2012. A Few Useful Things tion. In International Workshop on Runtime Verifica- to Know about Machine Learning, Comm. ACM, Vol. 5, tion (pp. 21-35). Springer, Berlin. Iss. 10, pp 78-87, October 2012. [Schwarz et al 2019] Schwarz, C., Gaspar, J., Miller, T., [DSA 2019] Defence Safety Authority, Service Inquiry, Loss Yousefian, R., 2019. The Detection of Drowsiness Using of Watchkeeper (WK043) Unmanned Air Vehicle over a Driver Monitoring System, ESV 2019. Cardigan Bay in West Wales 24 Mar 17, DSA/DAIB/17/006, 2019. [Steck 2012] Steck, H., 2012. Learning the Bayesian network structure: Dirichlet prior versus data. arXiv preprint [Feige 2019] Feige, I., What is AI safety? https://fac- arXiv:1206.3287. ulty.ai/blog/what-is-ai-safety/ (accessed May 2019) [Wilby 2019] Wilby, A., 2019. Private communication.