Brian F G Katz
email: brian.katz@sorbonne-universite.fr

Damian Murphy
email: damian.murphy@york.ac.uk

Angelo Farina
email: angelo.farina@unipr.it

The Past Has Ears (PHE) : XR Explorations of acoustic spaces as Cultural Heritage

Keywords: Archaeoacoustics, Digital heritage reconstructions, Audible virtual and augmented reality, Acoustic heritage, Methodology guidelines

Abstract. Hearing is one of our most pervasive senses. There is no equivalent to closing our eyes, or averting our gaze, for the ears. When we think about great architectural achievements in European history, such as ancient amphitheatres or Gothic cathedrals, their importance is strongly tied to their acoustic environment. The acoustics of a heritage site is an intangible consequence of the space's tangible construction and furnishings. Inspired by the project's namesake (Phé, for the constellation Phoenix), and the relatively recent fires at Cathédrale de Notre Dame de Paris and Teatro La Fenice opera hall, the PHE project focuses on virtual reconstruction of heritage sites, bringing them back from the ashes. In addressing the intangible acoustic heritage of architectural sites, three main objectives have been identified for this research project: Documentation, Modelling, and Presentation. In parallel, three heritage sites are participating as case studies: Tindari Theatre (IT), Notre-Dame de Paris Cathedral (FR), and The Houses of Parliament (UK). The acoustics of a space is immersive, spatial, and due to the nature of auditory perception egocentric, in contrast to visual perception of an object, which can be observed from "outside". Consequently, presentation methods for communicating acoustic heritage must represent the spatially immersive and listener-centric nature of acoustics. PHE will lead development of a museum grade hardware/software prototype for the presentation of immersive audio experiences adaptable to multiple platforms, from off-site immersive speaker installations, to mobile XR via smartphone applications.

Introduction

With the recent adoption of UNESCO resolution "The importance of sound in today's world: promoting best practices", complementing the UNESCO Convention for the Safeguarding of the Intangible Cultural Heritage [START_REF]The importance of sound in today's world: promoting best practices[END_REF][START_REF]Convention for the safeguarding of the intangible cultural heritage[END_REF], we are now entering a new era where the acoustic soundscape of places both existing and historical merit reflection, preservation, and scientific study.

Preserving acoustics of historical buildings and concert halls for the posterity had been the dream of Michael Gerzon back in the seventies [START_REF] Gerzon | Recording concert hall acoustics for posterity[END_REF], and was first made possible by measuring multichannel impulse responses in 2003 [START_REF] Farina | Recording concert hall acoustics for posterity[END_REF].

When we think about great architectural achievements in European history, such as ancient amphitheatres or Gothic cathedrals, their importance is strongly tied to their acoustic environment. The acoustics of a heritage site is an intangible consequence of the space's tangible construction and furnishings. It is ephemeral, while also a concrete result of the physical nature of the environment. Through the "Past Has Ears" project (the PHE project4 ), we will explore how via measurements, research, and virtual reconstructions the acoustics of heritage spaces can be documented, reconstructed, and experienced for spaces both existing and in various altered states.

Inspired by the project's namesake (Phé, for the constellation Phoenix), and the relatively recent fires at Cathédrale de Notre Dame de Paris (2019) and Teatro La Fenice opera hall [START_REF] Tronchin | Acoustics of the former teatro -la fenice-in venice[END_REF] (1996, Fenice also meaning Phoenix), the PHE project focuses on the preservation, conservation, and reconstruction of heritage sites, bringing them back from the ashes for use by researchers, stake holders, cultural institutions, and the general public.

Overview

Comprising research teams with experience in acoustic reconstructions and historical research, paired with national heritage monuments of acoustic importance, the consortium will develop a joint methodology for addressing relevant archaeological acoustics issues across Europe with historians of different disciplines. Specialists in tangible/intangible cultural heritage legal issues ensure the viability and longevity of the methodology guidelines. The consortium will prototype next generation exploration tools for presenting digital acoustic reconstructions to scientists and museum visitors alike. Results will be evaluated with associated test heritage sites, created in partnership with stakeholders and experienced content producers. Presentation methods provide first-person in-situ or off-site explorations, with the ability to experience various historical periods. For deteriorated sites, this approach provides access to situations impossible to experience on-site. Additional uses include participative experiences, employing real-time reconstructions for on-site concerts and other events experienced in the heritage acoustics.

Responding to the EU Joint Programming Initiative on Cultural Heritage (JPI-CH) Conservation, Protection and Use joint CFP (2019), PHE addresses the challenges of "Layered conservation", "Sustainable protection and enhancement of values", and "Management of cultural heritage at risk". The project's goal is developing new methods for presenting acoustic heritage to both researchers and users, raising awareness and adding value to what is currently intangible heritage. This is achieved through development of a museum grade hardware/software prototype for the presentation of immersive audio experiences adaptable to multiple platforms, from off-site immersive speaker installations, to mobile AA/VR (XR) via smartphone applications.

Three principal objectives have been identified concerning the project: Documentation, Modelling, and Presentation. These research concepts are directed towards three case studies, adjusting to the unique requirements of each site. The overlying goal being the formulation of techniques, tools, and a system prototype that is adaptable to various site conditions and test cases, providing a flexible yet realistic immersive audio rendering of historic states of cultural heritage buildings. It is intended that the results of such a project will facilitate increased acceptance and integration of acoustic aspects within heritage research and communication with the public.

This paper presents an overview of the current project and the principal elements of XR related research. Modelling and Presentation directly concern XR on the three sites, and are therefor exposed in more detail here. Such research builds on previous results and knowledge previously acquired in the development and use of virtual acoustics and room acoustic simulations.

3 Principal objectives of the project Any conservation-restoration process of a heritage site requires gathering documentation, scientific investigations, and a detailed state of repair, which form the basis for the elaboration of a diagnosis and subsequent project. Documentation of acoustics of historic sites is still an emerging notion in various associated fields, with no standards of practice or generally accepted methodologies. PHE will develop a framework protocol for digital documentation through precise measurements of acoustic states of a site that is sufficient for providing a safeguarded reference in the event of evolution of the site, or in the event of disaster. Like the Theatro La Fenice and hopefully for the Cathédral de Notre Dame de Paris, such heritage sites can emerge from the flames of disaster with their acoustics preserved, being an integral part of their historic value. An open public database will be constructed consisting of descriptions, associated acoustic property characterisations and measurements, and in-situ recordings when possible to foster an accepted reference for discussion and exchange among researchers across Europe in the different domains. Such a database shall improve the quality of historical acoustic simulations, but providing much needed data on acoustic and physical properties of materials rarely used today in modern constructions, and therefore poorly documented.

3.2 Modelling: From Evidence to Auralisation, Layered history modelling and simulations Physical and digital reconstruction methods have been used in acoustics for decades. However, it is only relatively recently that evolutions in computational technologies have opened the doors to improved quality and resolution of acoustic modelling for large-scale spaces where acoustics is crucial and spaces are increasingly complicated. Recent efforts in calibration techniques have shown that properly simulated spaces can be perceptually comparable to actual on-site spatial recordings [START_REF] Postma | Perceptive and objective evaluation of calibrated room acoustic simulation auralizations[END_REF][START_REF] Postma | Creation and calibration method of virtual acoustic models for historic auralizations[END_REF]. Once created, these models are modified to explore alternative states, testing acoustic conditions under various architectural or decorative configurations, source and listener positions, use contexts, etc. As a tool, acoustic simulations provide a new and powerful resource for historical studies, providing researchers a sensorial presentation of heretofore-textural descriptions [START_REF] Katz | Comment entendre le passé ? Quelques leçons d'une collaboration de recherche entre acousticiens et spécialistes d'études théâtrales[END_REF][START_REF] Murphy | Acoustic heritage and audio creativity: the creative application of sound in the representation, understanding and experience of past environments[END_REF][START_REF] Postma | An archeoacoustic study of the history of the Palais du Trocadero (1878-1937)[END_REF].

The "transparent" nature of acoustics provides ideal conditions for studying the layered nature of history within architectural sites. With a geometrically accurate 3D model, incorporating acoustic properties of materials and construction, accurate predictions are made of the evolution in the acoustics as a function of changes in different material's history. Changes occurring through the introduction, modification, or removal of significant elements as well as degradation over time or major catastrophes are incorporated based on accurate documentation and informed extrapolation through archaeological evidence. Changes in use are examined, focusing on the evolution of a site in relation to the evolution of culture and customs over time and the associated actions of our predecessors to adjust their acoustic environment to accommodate their needs.

As evidenced by prior works [START_REF] Murphy | Spatial audio measurement, modeling and composition[END_REF][START_REF] Noisternig | Framework for real-time auralization in architectural acoustics[END_REF][START_REF] Southern | Boundary absorption approximation in the spatial high-frequency extrapolation method for parametric room impulse response synthesis[END_REF][START_REF] Stevens | Modeling sparsely reflecting outdoor acoustic scenes using the waveguide web[END_REF], there are varieties of methods available to carry out such simulations. Such variety of choice implies an equal variety in modelling parameters and results. With the aim of providing common research environments in acoustic heritage, it is necessary to work towards a uniform model definition methodology, independent of the tools employed, while providing an assessment of different approaches available.

An evaluation of current state-of-the-art and under development modelling methods will be carried out, examining for example ray-tracing, digital waveguides, image-source method, finite-difference time domain (FDTD), and stochastic processing approaches which have all been shown to hold hold some promise which each exhibit certain limitations. The quality of resulting simulations are evaluated regarding authenticity from metric analysis perspectives and human perception perspectives, as listening to digital reconstructions is often more meaningful as a means to study acoustic heritage and to communicate its cultural nature, raising awareness for non-specialists [9,14].

Presentation/Use of heritage acoustics

The acoustics of a space is immersive, spatial, and due to the nature of auditory perception egocentric (first-person reference frame, individual), in contrast to visual perception of an object, which can be observed from "outside" (e.g. bird's eye view), or where the observation position does not seriously affect the information conveyed. Consequently, presentation methods for communicating acoustic heritage must represent the spatially immersive and listener-centric nature of acoustics. "Auralization" is the sound equivalent of visualization for the results of modelling techniques. The auditory presentation of accurate acoustical numerical models, through auralization over headphones or speaker arrays, allows users to experience spatial acoustic properties of a site as if present [START_REF] Capra | Correlation between subjective descriptors and objective parameters of theatres and auditoria acoustics simulated with binaural sound systems[END_REF][START_REF] Farina | Acoustic quality of theatres: correlations between experimental measures and subjective evaluations[END_REF][START_REF] Harriet | Auralisation of an urban soundscape[END_REF][START_REF] Binelli | Individualized HRTF for playing VR videos with Ambisonics spatial audio on HMDs[END_REF][START_REF] Postma | Perceptive and objective evaluation of calibrated room acoustic simulation auralizations[END_REF].

Due to the intangible nature of acoustics, and reactive nature of room acoustics, in that it does not "sound" on its own, requiring a sound source to be heard, the choice of sound material, and its presentation, have significant impacts on information transmission to users when attempting to provide a relevant and meaningful experience. Choice of source material are highly pertinent in raising awareness and integrating acoustic heritage in its cultural and societal context. The connection of heritage sites to their surroundings, through soundscape analysis and reconstruction, provides further means for communicating the temporal and cultural context, raising awareness of heritage's importance as a whole.

Different means for presenting acoustic heritage have been employed in recent years, with each production often being limited to the presentation system employed. While developments for off-site presentation have been more prevalent, in-situ rendering of immersive acoustic heritage has not advanced beyond the traditional "audio-guide", with its associated limitations. PHE will lead development of a museum grade hardware/software prototype for the presentation of immersive audio experiences adaptable to multiple platforms, from off-site immersive speaker installations, to mobile XR via smartphone applications.

On-site XR presentation will focus primarily on spatial audio rendering, using hear-through headphones. This direction allows for the actual visual state of a heritage site to be combined with a spatially coherent immersive auditory scene. Platform agnostic spatial audio formats (e.g. Higher-Order Ambisonics) will be used to minimize the impact of rendering in multiple user scenarios. Tracking will be integrated in the headphone device while a comparable smartphone application may use the orientation sensors available and standard headphones for a lower-quality but still immersive experience. Off-site presentation will focus on the use of speaker-array installations, which can be combined with image projection, for multiple users or off-the-shelf VR headsets.

Various degrees of interaction are possible, depending on the presentation platform. In addition to the ability to move about in the space, the user will be able to adjust their time-window perspective through history, experiencing the layered history. Focus can be applied to different elements or event. Further interaction with the acoustics of the virtual space is also possible, given available computing power, allowing the user for example to experience their own voice on stage in the former theatre in front of a full audience.

Cultural heritage site case studies

The project explores how through measurements, research, and finally virtual reconstructions the acoustics of heritage spaces can be documented, reconstructed, and experienced. Spanning a variety of heritage site conditions, three case studies with prominent heritage sites where acoustics plays a major role will be used to examine how to address the conservation, protection, and use of spaces both past and present. The case study sites represent public sites of importance in the form of an ancient Greek theatre (far from its original condition), a Gothic Cathedral (in the midst of recovering from a serious catastrophe, inaccessible to the public for some years), and the House of Commons (limited accessibility to the public, of significant cultural and political importance, and a key site for future preservation).

Notre-Dame de Paris: As soon as it was built at the end of the XII th c., the Gothic cathedral of Notre-Dame de Paris became the emblematic place of musical creation in Europe. For more than 850 years, Notre-Dame de Paris has been the sounding box for the city's sacred music. Built to amplify the sacred word spoken or sung, the Cathedral is a multiform sound space where the clamor of the pilgrims circulating in the ambulatory and the chanting of the services protected by the choir's enclosure, the soloist singing the mass and the humming of the low masses in the radiant chapels, used to coexist until today, when before the fire, the call to silence for noisy visitors, the sound of the masses, the bursts of sound from the great organs and the concerts alternated.

House of Commons:

This work builds upon the Listening to the Commons project, where the goal was to develop a first-stage acoustic model of pre-1834 UK House of Commons Chamber and the roof-void above, where women, who were otherwise excluded from this space, gathered to access and engage with political debate via listening through a ventilator. Measured acoustic data has also been gathered from the current House of Commons Chamber, and other historic sites in the UK comparable in design and period to to the pre-1834 Chamber. The Commons chamber itself houses of one of the world's first parliamentary democracies.

Theater of Tindari: This ancient building erected at the end of the IV th BC, was renovated, and transformed during the Roman period, then abandoned during the Late antique period. Research on the possible use of the space will help understand its fate until the XX th c. With a capacity of ≈ 3000, it was used continuously until the Roman imperial age before undergoing substantial modifications, accommodating gladiatorial and animal combat. Today, it hosts musical and theatrical events.

Conclusion

The transparent and ephemeral nature of acoustics facilitates understanding of temporalities of acoustic heritage, whereby layers of cultural meaning and temporal history of materials and constructions are analysed by researchers, conveyed to interested users and the community as a whole. Combining methodical and generalized documentation procedures with validated digital modelling and simulation methods to ensure both physical and historic authenticity, the development and use of new digital tools and methods focusing on the emerging impact of auditory-VR/AR will foster new understandings and interpretations of sites and associated events. In proposing a temporally layered presentation, previous, present, and future interpretations are updated according to results of current and future historical research and discoveries.

3. 1

 1 Documentation: Acoustical, Archaeological, Architectural, and Cultural

https://evaa.lam.jussieu.fr/doku.php#phenixthe_past_has_ears

Acknowledgements

Funding has been provided by the JPI-CH project PHE.

Supported by EU JPI on Cultural Heritage (JPI-CH).


Magnus Gyllenhammar
email: magnus.gyllenhammar@zenseact.com

Fredrik Sandblom
email: fredrik.sandblom@volvo.com

Mattias Brännström Zenseact

Stig Ursing
email: stig.ursing@semcon.com

Rolf Johansson

Fredrik Warg
email: fredrik.warg@ri.se

Minimal Risk Condition for Safety Assurance of Automated Driving Systems

Keywords: Automated driving systems, Safety, Minimal risk condition, Degraded operations, Safe state

We have yet to see wide deployment of automated driving systems (ADSs) on public roads. One of the reasons is the challenge of ensuring the systems' safety. The operational design domain (ODD) can be used to confine the scope of the ADS and subsequently also its safety case. For this to be valid the ADS needs to have strategies to remain in the ODD throughout its operations. In this paper we discuss the role of the minimal risk condition (MRC) as a means to ensure this. Further, we elaborate on the need for hierarchies of MRCs to cope with diverse system degradations during operations.

I. INTRODUCTION

One of the promises of increased automation of the transportation system is improving its safety. Paradoxically, this is also one of the main challenges when developing automated driving systems (ADSs). Similar to traditional automotive systems an ADS needs to be implemented to a high integrity to avoid accidents and fatalities when released in large volumes. Direct validation is both infeasible, due to the large amount of driving needed to prove sufficient integrity of the ADS [START_REF] Young | Automated driving system safety: Miles for 95% confidence in "vision zero[END_REF], and potentially unsafe, as we have seen in the recent crashes with (partially) automated vehicles (Table 1.2 [START_REF] Carre | Autonomic Framework For Safety Management In The Autonomous Vehicle[END_REF]). Since this brute force approach is not feasible, there is a need for alternatives. Raising the question; how can the safety of the ADS be ensured before release on public roads? This challenge is equivalent to showing that the residual risk after all design, implementation and verification efforts is sufficiently low. The operational design domain (ODD) has been proposed as a useful tool to achieve this goal [START_REF] Gyllenhammar | Towards an operational design domain that supports the safety argumentation of an automated driving system[END_REF].

In this paper, we explore what is required for the ADS to remain inside the ODD. The role of the minimal risk condition (MRC) is elaborated. In the light of the three decision levels, strategic, tactical and operational [START_REF] Michon | A critical view of driver behavior models: what do we know, what should we do?[END_REF], we further discuss how a

The research has been supported by the Strategic vehicle research and innovation (FFI) programme in Sweden via the SALIENCE4CAV project (ref 2020-02946) and the Wallenberg Al, Autonomous Systems and Software Program (WASP) funded by the Knut and Alice Wallenberg Foundation. loss of capabilities can be handled with tactical decisions; i.e. through appropriately restricting the ADS's actions to the new capabilities or by re-planning the route to avoid unsuitable external operating conditions (OCs). If none of these are possible, the third option is to transition into MRC.

Related works are discussed in Sec. II and the role of the MRC is discussed in Sec. III. Handling capability reductions of the ADS in relation to the term restricted operational domain (ROD) is discussed in Sec. IV. Finally, conclusions and potential future works are given in Sec. V.

A. Preliminaries

In this paper, we focus on level 4 automated driving systems (ADSs), as defined in SAE J3016 [START_REF] Sae | SURFACE VEHICLE RECOMMENDED PRACTICE -Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles[END_REF]. A level 4 ADS is responsible for carrying out the entirety of the Dynamic Driving Task (DDT) within its specified ODD, including an ability to reach a minimal risk condition (MRC) if the mission cannot be completed. It may have a fallback-ready user ready to assist in such situations, but must also be able to resolve them on its own.

1) The two driving states of an ADS: According to SAE J3016, the DDT includes all the operational and tactical decisions required for operating the ADS in traffic to fulfil a strategic objective, but excluding the strategic functions such as destination and waypoint selection. The DDT is performed until either of the following four events happen:

(i) The user-defined mission given to the ADS is completed. (ii) The driver 1 requests a takeover -the ADS tries to put itself in a state where such a handover can be conducted safely -and the handover is successfully completed. (iii) A DDT performance-related system failure occurswhich is followed by the execution of a DDT Fallback (DDT-FB) to achieve MRC, or alternatively to a handover can be made. (iv) Nearing an ODD exit -DDT-FB is triggered to reach MRC, or the control is handed over to a driver before the exit occurs. There are thus two distinct driving states: DDT and DDT-FB.

2) Three Levels of Driver Efforts in Context of ADS: To understand the different levels of decisions involved in operating an ADS, J3016 [START_REF] Sae | SURFACE VEHICLE RECOMMENDED PRACTICE -Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles[END_REF] introduces three levels of driver efforts, as suggested by Michon [START_REF] Michon | A critical view of driver behavior models: what do we know, what should we do?[END_REF]. The three levels are: strategic, tactical and operational, and can be positioned in a decision hierarchy according to Fig. 1. On a strategic level, the ADS either operates to fulfil a user-defined mission or to achieve MRC. The tactical decisions involve taking safe actions to avoid other objects as well as to take appropriate actions to fulfil the strategic mission. Operational decisions, on the other hand, are the low-level vehicle control operations.

When the user-defined mission is applicable, the tactical decisions together with the operational ones are responsible for carrying out the DDT. In the case where the MRC is the strategic mission, the tactical and operational decisions will instead execute the DDT-FB.

II. RELATED WORK

Reschka and Maurer [START_REF] Reschka | Conditions for a safe state of automated road vehicles[END_REF] discuss what constitutes a safe state for an automated road vehicle and present four different conditions for such. The first three pertain to the DDT, performed either by (1) the human, by (2) a remote entity (e.g. through telecommunications) or by (3) the ADS itself. The fourth condition (4) is when the vehicle is standstill.We do not address the (1) and ( 2) but agree that the driver should be considered as one possible safe state. For (4) we note that the safety of a state is not only determined by the risk of the state itself (which is covered in [START_REF] Reschka | Conditions for a safe state of automated road vehicles[END_REF]) but also by the propensity of the ADS to enter this state as well as the rate of recovery. Further, [START_REF] Reschka | Conditions for a safe state of automated road vehicles[END_REF] suggest that the safety of condition (3) can be estimated as the difference between the available capabilities and the demanded capabilities. We suggest that this is (a) primarily covered by the ODD, when it comes to external conditions, (b) the prompt decision of entering an MRC if the capabilities can no longer be matched due to a system failure, and (c) the capability reporting together with appropriate tactical decisions for system failures which do not violate the demanded capabilities. Xue et al. [START_REF] Xue | A fallback approach for an automated vehicle encountering sensor failure in monitoring environment[END_REF] argue for a prolonged DDT-FB to reach a more safe MRC. We introduce a hierarchy of MRCs to be able to select the most appropriate (safest) one. Contrary to ISO/TR 4804, we consider an MRC as a final decision and further require the ADS to be at standstill, as does J3016 after the 2021 update [START_REF] Sae | SURFACE VEHICLE RECOMMENDED PRACTICE -Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles[END_REF]. There should be no recovery from MRC to the original user-defined goal (cf. Figure 8 of [START_REF]:2020 Road vehicles -Safety and cybersecurity for automated driving systems -Design, verification and validation[END_REF]). Reschka et al. [START_REF] Reschka | A surveillance and safety system based on performance criteria and functional degradation for an autonomous vehicle[END_REF] suggest that a set of performance criteria are matched with heuristic degradation actions to handle lost performance. This is an example of how to construct the tactical decisions to ensure safe actions considering the reported capabilities. However, we note that the approach of listing concrete heuristics for each different capability change is not scalable. For large discrete system degradations, Colwell et al. [START_REF] Colwell | An automated vehicle safety concept based on runtime restriction of the operational design domain[END_REF] coin the term restricted operational domain (ROD). We acknowledge the usefulness of the term, but also recognise the need for equivalent methods to handle more temporary and non-discrete degradations. Rather than a supervisory layer handling the different RODs, we believe that this comes as a natural consequence from having the tactical decisions receive capability reports from the different parts of the system and take appropriate actions based on this information. A method along these lines, for posing requirements on the perception sensors to report their capabilities, is suggested in [START_REF] Johansson | A strategy for assessing safe use of sensors in autonomous road vehicles[END_REF].

III. CLARIFYING THE ROLE OF THE MRC

Not all OCs of the ODD can be firmly ascertained throughout the operations of the ADS. To account for that, the ADS needs to bring itself to MRC before a violation of an OC. This is especially relevant when employing strategy III or IV of [START_REF] Gyllenhammar | Towards an operational design domain that supports the safety argumentation of an automated driving system[END_REF], using statically defined geographical and temporal conditions for where/when the OCs are valid (III), or run-time triggering conditions (IV). For instance, if an example ADS is travelling from A to B and is stuck in traffic, it might realise that it is unable to reach B before sunset. To avoid this the ADS will abandon its original strategic goal (B) and transition into MRC before the 200 lux ODD limit is violated. For the safety case to be valid the ADS should not be operational outside the ODD, thus the MRC itself cannot be a driving state of the system, else it would make no difference to transition into MRC to handle ODD exits. In the example, the illumination will be violated eventually, once the ADS is in MRC. The only way of arguing that the ADS is no longer driving, is by having the MRC as a state of standstill. This has also been recognised by the update of J3016 [START_REF] Sae | SURFACE VEHICLE RECOMMENDED PRACTICE -Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles[END_REF] in 2021 where it is defined as a "... stopped condition ...". In addition to that we would like to pose a yet improved definition:

Definition: Minimal risk condition (MRC) is a stable stopped condition at a position with an acceptable risk given the situation when the decision to enter MRC is taken. If an acceptable risk is not attainable, the position with the lowest risk should be selected. The ADS is brought to this state by the user or the system itself, by performing the DDT-FB, when a given trip cannot or should not be completed. [START_REF] Sae | SURFACE VEHICLE RECOMMENDED PRACTICE -Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles[END_REF] The augmented definition highlights the need for arguing the safety for each MRC. This safety is made up of three components:

1) the frequency to enter the MRC, 2) the risk of the position selected, and 3) the rate of resolving the MRC, i.e. to bring the ADS out of MRC or have a driver take over the driving task.

Each OC strategy should be associated with a standstill position. This position could be all from at the curb of the road to neatly parked at the closest rest area. Depending on which, the frequency of entering that position can be higher or lower. As can the rate of recovery. Stopping on the side of the road on a highway is incurred with a significant risk and should be entered infrequently and/or rapidly be resolved, whereas parking at the rest area could be allowed more often and, as long as there is not a passenger in the vehicle, this state is safe for a very long time. Note that the acceptability of the risk of the state is related to the analysis pertaining to the three items listed above. Further, the lowest risk states selected, due to unattainability of an acceptable risk state, also needs to be included in the overall risk analysis of the system.

IV. HANDLING PERFORMANCE DEGRADATIONS

In addition to the ODD, the tactical decisions are limited by the current capabilities of the ADS. Let us assume that the ADS is configured with one perception block reporting to a decision-making block, which subsequently request actuation of paths from a vehicle platform. In such a case, the capabilities from the perception as well as the vehicle platform limit the tactical decisions to consider only manoeuvres that are both viable with respect to perception performance as well as attainable with the currently available (predicted) actuation capabilities. All possible capability reports should be understandable by the tactical and strategic decisions. The ADS needs to fulfil its DDT given these reports and if that is not the case, it should abandon the user-defined goal and go to an appropriate MRC. This is called a DDT performancerelated system failure [START_REF] Sae | SURFACE VEHICLE RECOMMENDED PRACTICE -Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles[END_REF].

For the ADS to understand when a sub-optimal capability is sufficient, in terms of continued operations, this must have been part of the development and assessed and verified. Small temporary performance fluctuations would likely be included in the verification of the system, especially if the fluctuations are due to external factors. In that case, the range of such conditions should be encoded as OCs of the ODD. Such conditions could include occlusion of the vision sensors, due to precipitation, or increased braking distance due to a wet road surface. But what about the performance degradation in the system? What if we lose connection to one of the cameras? Or if the braking system is no longer redundant? Or if we have an occasional glitch in the communication with one of the sensors? The resulting capabilities of these "new" subsystems need to be understood and assessed to allow continued operation of the ADS. Further, these capabilities need to be compared to what is required from the current DDT. Colwell et al. [START_REF] Colwell | An automated vehicle safety concept based on runtime restriction of the operational design domain[END_REF] use the term restricted operational domain (ROD) to describe where a permanently degraded subsystem is able to safely operate. However, we propose that it is the task of the tactical decisions to cope with any kind of capability degradation, not just large and discrete ones. Furthermore, the better the system is at self-diagnostics, the closer to a continuum is reported in the form of capability reports. Considering the RODs as a finite set of degraded states thus limits the usefulness of the concept. That said, the response from the tactical decisions is dependent on the amount of analysis and verification that has been conducted for each capability degradation. With increased development and verification efforts the availability of the system under diverse capability restrictions can be increased.

If the ROD of a capability report is not understood the only option is to proceed to MRC. If such an analysis has been done however, the tactical decisions are left with two options: (1) Keep the strategic goal and potentially change the route to avoid OCs that are not viable for the current ROD, or (2) abandon the current strategic goal and go into MRC. Within option (1) the task of remaining within the available capabilities (e.g. not exceeding a maximum speed of 80 km/h) is the task of the tactical decisions. Fig. 2 shows such an example. An example ADS experiences a reduced braking capability. It is still able to brake if driven at speeds below 80 km/h, but it is unable to handle steep slopes. Since these limitations are known, the tactical decisions decide to change the original route, over the mountains, to instead drive around and thus allowing the ADS to fulfil the original strategic goal. The change of the routes requires three things, a knowledge of the capabilities, an understanding of what is required to fulfil the strategic goal (cf. ODD exit strategy II [START_REF] Gyllenhammar | Towards an operational design domain that supports the safety argumentation of an automated driving system[END_REF]), and knowledge of the demanded capabilities of alternative routes. Within option (2) a detailed understanding of the capabilities of the sub-system makes it possible to select a more favourable MRC position. Instead of directly stopping in lane one can return to a dispatch centre or park at a nearby rest area.

A. Involving the User

Many of the ADS's failures might be handled by a user taking back control. For systems with fall-back ready users, analysing each and every ROD is probably not a worthwhile effort. For dedicated vehicles, without drivers, this analysis will likely need to be expanded as it will be both risky and costly to allow the ADS to stop upon every small system failure. The value of understanding the RODs of the system will then outweigh the cost of doing the analysis.

If the user-defined goal is kept even after a take-back request it is fair to assume that some users might abuse this and deliberately refrain from taking back control to see if the ADS eventually reaches the user-defined goal anyways. If an ADS relies on a successful handover in e.g. 99% of the cases when the ADS is approaching a road works, such abuse would result in our frequency of entering the MRC would be violated. Because of this, the decision of going into MRC must be a final one. If the user wishes to go back to its defined goal, then it has to initiate a negotiation for a new trip. Once the ADS is in MRC it is not in a driving state, but it is still operational and e.g. able to initiate a new trip.

B. A Hierarchy of MRCs

Let us explore the notion of having different MRCs depending on the situation the ADS finds itself in. It is evident that each strategy to ascertain the OCs could have different MRCs depending on which OC(s) it is tasked with ensuring and also related to the time until the OC(s) is violated. Consider an OC pertaining to sufficient lighting (e.g. illumination > 1000lux ∈ ODD). It is possible to know well in advance when the sun will set and if the user-defined mission cannot be completed before that time an appropriate MRC position, e.g. stopping at the rest area closest to the destination, can be selected. However, while performing the DDT-FB to reach this parking lot there might be a queue which inhibits the ADS to reach this state before the OC is violated. This warrants a more prompt transition into MRC and it might be necessary for the ADS to eventually stop on the curb of the road to avoid an ODD exit. But there could also be another OC in risk of being violated when the ADS is in the process of achieving the MRC of the first. Rather than a queue, we might suddenly get a weather forecast saying that it will start hailing, which (let us assume) is not a valid OC. Also in this case the ADS needs to make a quick transition into an other MRC to accommodate this new information and avoid driving in hail. Similarly, an MRC should be defined for each system failure impacting the operating capabilities of the ADS resulting in an inability to fulfil the user-defined mission. Depending on the failure, the MRC might be more or less restrictive. Both the MRCs to avoid ODD exits as well as the MRCs to handle system failures can be put in a hierarchy related to the required final position and the allocated time to reach this state. A state diagram of the ADS with this hierarchy of MRCs is depicted in Fig. 3. Just as for abandoning the userdefined goal the choice of entering another MRC should be a definite one. This is why the MRCs can be ordered in a hierarchy as depicted.

Emergency manoeuvres, e.g. autonomous emergency braking (AEB), do not necessarily result in the abandonment of the strategic goal. Consider a successful AEB intervention to avoid collision with an obstacle. If the road is cleared the ADS might continue to fulfil its strategic goal. Emergency manoeuvres add a reactive component to the otherwise hierarchical decision making of the system. It is not the reaction itself but rather the outcomes that result in a change of the strategic goal.

V. CONCLUSIONS AND FUTURE WORK

In this paper we elaborate on how the MRC should be used to avoid ODD exists and to cope with system failures of an ADS and gives an elaborated definition to the term. Further, the MRC should be the result from a definite decision

…

+ Enabling conditions to accept the strategic mission Fig. 3. Illustrates that the ADS can be associated with a set of MRCs. Before the ADS has fully reached the intended MRC the strategic goal can change to an MRC with higher requirements, which is indicated as the transition from DDT-FB 1 to DDT-FB 2 etc. Once the MRC is reached the ADS will remain there until a new trip is requested.

to abandon the previous strategic mission. Capabilities of the ADS should be reported to, and eventual reductions should be handled by, the tactical decisions. This view of handling degraded performance is a more refined way of incorporating the ROD, as proposed in [START_REF] Colwell | An automated vehicle safety concept based on runtime restriction of the operational design domain[END_REF].

As future work we suggest to investigate the implications of capability reporting on functional architecture.

Fig. 2 .

 2 Fig.2. Two routes between A to B are depicted. The original route across the mountains is no longer valid after a performance degradation, but the new route can be executed safely within the new capabilities (green area).


Magnus Gyllenhammar
email: magnus.gyllenhammar@zenseact.com

Carl Bergenhem
email: carl.bergenhem@qamcom.se

Fredrik Warg
email: fredrik.warg@ri.se

ADS Safety Assurance -Future Directions

Keywords: Safety assurance, Contract-based design, safety contracts, automated driving system, assurance method criteria

More effective, efficient and flexible ways to manage safety assurance are needed for the successful development and release of Automated Driving Systems (ADSs). In this paper we propose a set of desired assurance method criteria and present an initial overview of available safety assurance methods and how they contribute to the proposed criteria. We observe that there is a significant gap between the state-of-the-art research and the state-of-practise for safety assurance of ADSs and propose to investigate reasons for this as future work. A next step will be to investigate how to merge the elements from the different assurance methods to achieve a method addressing all criteria.

I. INTRODUCTION

Safety assurance is a challenge for development of advanced automated and connected vehicle functions, such as automated driving systems (ADSs). There is a need for more effective, efficient and flexible ways to manage assurance cases compared to currently prevailing practices. Incremental development to ease introduction of ADSs by allowing for gradual improvement of performance and gradual expansion of the operational design domain (ODD) requires support for (a) frequent updates, e.g. using agile development and continuous integration/continuous deployment schemes. Key to such incremental improvements is also use of targeted collection of (b) operational data giving feedback to development, e.g. using DevOps/DataOps methods. In addition, automated functions will have a need for (c) monitoring changes in the operational context to make sure the safety case stays valid, e.g. by using field data in the context of ODD verification and monitoring; as discussed by Gyllenhammar et al. [START_REF] Gyllenhammar | Towards an operational design domain that supports the safety argumentation of an automated driving system[END_REF]. Cyber-security incident management is another driving need for rapid updates. Furthermore, management of multiple (d) variants and integration of components from different suppliers -which requires (e) modularity -are prevalent issues in the automotive domain. As ADSs are complex safety-critical functions, they are likely to involve parts from multiple suppliers and exist in multiple variants. An ADS may also employ (f) self-adaptive system properties, i.e. a system that has to operate under uncertainty. Weyns et al. [START_REF] Weyns | Perpetual assurances for self-adaptive systems[END_REF] coin the term perpetual assurance to capture the continuous assurance effort needed for self-adaptive systems, in contrast to a one-off effort before deployment of the system. Here, the assurance process spans the entire life-time of the system and new evidence and arguments are incorporated and integrated into the assurance case continuously also during operations. Finally, putting together an effective assurance case given the characteristics of an ADS, e.g. with non-deterministic algorithms, a complex sensor system, adequately capturing the details of the (stochastic) environment, and a large scope for the safety-critical functionality, will be challenging. We believe in basing safety assurance on a quantitative risk norm, e.g. as described by Warg et al. [START_REF] Warg | The quantitative risk norm-a proposed tailoring of HARA for ADS[END_REF], which implies a mainly (g) quantitative assurance case. The goal of this approach is a more balanced and usable way of allocating necessary risk reduction; compared to the relatively coarse-grained integrity levels used in standards such as ISO 26262 [START_REF]ISO 26262:2018 Road vehicles -Functional safety[END_REF].

In [START_REF] Weyns | Perpetual assurances for self-adaptive systems[END_REF], a framework is presented and a set of requirements for method usefulness is given. This framework is in part relevant also for ADSs, but we suggest the assurance method criteria (a)-(g) above to more accurately capture the specific challenges in ADS assurance. A hypothesis for our work has been that safety-contract based design -a well-researched method (e.g. Bate et al. [START_REF] Bate | A contract-based approach to designing safe systems[END_REF]) which enables design with reusable and potentially pre-certified components -would be a suitable base for ADS safety assurance. However, considering the criteria above it is not sufficient by itself, and despite the large body of existing work, we have yet to see any widespread use of safety contracts.

In this paper we discuss a few proposed safety assurance methods and map their applicability to criteria (a)-(g). We find that there is a gap between state-of-the-art in research and state-of-practice, as well as a lack of tools fulfilling all criteria, something we aim to investigate further in future work. While no method seem sufficient by itself, all methods contribute to some criteria, hinting at the possibility of combining elements from different methods for an ADS safety assurance method covering all criteria. In particular, we revisit the research in safety contracts, and suggest that a way forward can be using contracts as a base to build such an assurance method.

II. BACKGROUND: CONTRACT-BASED DESIGN

Contract-based software design was pioneered by Bertrand Meyer [START_REF] Meyer | Design by contract and the component revolution[END_REF] in the Eiffel programming language. The central idea, equivalent to the Hoare triple [START_REF] Hoare | An axiomatic basis for computer programming[END_REF], is that the interaction between elements in a system are expressed as contracts. A contract describes which preconditions an element expects, and which postconditions (and invariants) it can guarantee given that those preconditions hold. Hence, the element does not have to be designed to handle cases where the preconditions are invalid, limiting both complexity and verification effort. The contract-based approach encourages (e) modularity, and can simplify change management as the contracts will provide a way to perform impact analysis, i.e. whenever a contract is altered it will be possible to follow how dependent elements are affected. Contract usage establishes the foundations for contract reasoning about composability and abstraction/refinement relationships. In software, contracts are often implemented as assertions resulting in an exception if a contract is broken. The paradigm has later been applied to system design, where e.g., Benveniste et al. [START_REF] Benveniste | Contracts for system design[END_REF] introduced and formalized Assume-Guarantee (A/G) contracts to describe the preconditions (assumes) and post-conditions (guarantees) for system design elements.

Nuzzo et al. [START_REF] Nuzzo | A platform-based design methodology with contracts and related tools for the design of cyber-physical systems[END_REF] describe a methodology for design of complex distributed systems based on [START_REF] Benveniste | Contracts for system design[END_REF]. A/G contracts are used to reason about requirements and their refinement during the design process, and includes a methodology and algebra of contracts to formalize the design process. The design is carried out as a sequence of refinement steps from a highlevel specification to an implementation built out of a library of components at the lower level. The high-level specification is first formalized in terms of contracts to enable requirement validation and early detection of inconsistencies. Then, at each step, contracts are refined by combining synthesis, optimization and simulation-based design space exploration methods. Refinement through different abstraction levels is also proposed by Warg et al. [START_REF] Warg | Continuous deployment for dependable systems with continuous assurance cases[END_REF], though the way to formulate contracts is not as well defined. The main goal in [START_REF] Warg | Continuous deployment for dependable systems with continuous assurance cases[END_REF], however, is a methodology enabling continuous deployment.

III. SAFETY ASSURANCE METHODS

In this section, we briefly describe safety assurance methods that fulfil some of the criteria discussed in Sec. I. Note that only the most relevant or recent paper from each author/group is included, for space reasons. A summary how the methods map to the proposed assurance method criteria can be found in Table I.

A. Safety-Contract Based Design

A use-case for contract-based design is to provide contracts aimed at quality attributes. The use of safety contracts, i.e. contracts which only encode safety-critical properties of an element, has further been proposed, e.g. Bate et al. [START_REF] Bate | A contract-based approach to designing safe systems[END_REF] and Slijvo et al. [START_REF] Sljivo | Strong and weak contract formalism for third-party component reuse[END_REF]. Recently, there have also been large EU funded projects in the domain, such as the SafeCer project. This project had the goal of enabling reusable certifiable components using safety contracts and pre-qualified components. In [START_REF] Carlson | Delivery d132.2, generic component meta-model' of the safecer project[END_REF], Carlson et al. (from the SafeCer project) introduce a meta model to support safety argumentation according to safety standard(s) by incorporation of the necessary elements into a component-based software engineering approach. The project AMASS [START_REF] De La Vara | The AMASS approach for assurance and certification of critical systems[END_REF] also included contracts in its mission to introduce a framework for multi-concern (e.g. safety and security) assurance and certification of dependable systems.

Söderberg and Johansson [START_REF] Söderberg | Safety contract based design of software components[END_REF] discuss how to use a modified design methodology for contract-based design (CBD) intended for development of software and component based systems by use of safety contracts. The primary purpose is to make a proposal on how to integrate safety contracts in an implementable way (in a tool) for automatic safety contract verification.

B. Conditional Safety Certificates -ConSerts

Schneider and Trapp [START_REF] Schneider | Conditional safety certification of open adaptive systems[END_REF] propose Conditional Safety Certifications (ConSerts) to shift part of the certification task of open adaptive systems from design-time, where the access to detailed evidence in support for the safety analyses might be limited, to run-time, where such evidence might be more readily available. The ConSerts are constructed of a set of predefined modular (e) and variable (d) certifications for each related (sub-)system. When the system is integrated (at system start with different collection of services) or adapted (during run-time) (f) these modular certificates are composed and evaluated. The ConSert certifies that a number of specified safety guarantees are fulfilled with certain probability (g) given the precondition that the specified safety demands (cf. assume of CBD) are fulfilled. The demands of each modular certificate relates to the component's environment and it might thus be difficult to verify already at design-time, since the environment might change throughout the use of the system (or component). In the example given, the environment of the component is exemplified as what other services are active. Despite the lack of detailed discussions about different system environments, except the availability of different adjacent services, there seem to be nothing in the approach contradicting its use also in the context of highly dynamic environments or e.g. to cater for the complexity of different ODDs.

The discussed example relates to adaptiveness in the sense that the system switches between different configurations during run-time. The system is able to provide certain top-level services based on cooperation between components through a service oriented architecture and dynamical service hierarchies. [START_REF] Schneider | Conditional safety certification of open adaptive systems[END_REF] emphasises that the ConSert should be used as a means to shift only the parts that are difficult or impossible to adequately complete during development/design-time to be evaluated in run-time, not that everything should be left for run-time certification. Only some predetermined certificate variants should be left for run-time evaluation, where their respective demands can be checked.

Contrary to CBD, the ConSert approach suggests to design the certificates composed in several paths where the most performant sub-system (path) is evaluated first and subsequently enacted if its certificates are found valid. This adaptability of the contract structure based on run-time evidence is something that seems generally missing in work in the CBD-approach. More recently, Trapp et al. [START_REF] Trapp | Towards safety-awareness and dynamic safety management[END_REF] build on the ConSert concept and introduce a dynamic safety management framework for autonomous systems. This facilitates monitoring (c) as well as to create safety-awareness, ultimately allowing the system to self-adapt based on available run-time evidence.

C. Dynamic Assurance Cases

Denney et al. [START_REF] Denney | Dynamic safety cases for throughlife safety assurance[END_REF] introduce the term Dynamic Safety cases. They deploy real-time monitors (c) of both the system and its environment to initiate changes to the safety case where applicable. This relies on a safety case that is possible to query and includes the appropriate metadata. Asaadi et al. [START_REF] Asaadi | Dynamic assurance cases: A pathway to trusted autonomy[END_REF] continues this work and propose an architecture (including monitors and decision mechanisms) as well as a methodology for dynamic assurance. The dynamic assurance case consists of five models or parts: 1) Assurance policy models, 2) Assurance architecture model, 3) Assurance quantification model (g), 4) Evidence model, and 5) Assurance rationale.

Calinescu et al. [START_REF] Calinescu | Engineering trustworthy self-adaptive software with dynamic assurance cases[END_REF] propose a method for dynamic generation of assurance cases; with generation of assurance evidence during both design-time and runtime. This is done for a target application that is denoted a self-adaptive software system (f). Self-adaptive software handles environmental and internal uncertainties by dynamically adjusting its architecture and parameters in response to events such as workload changes and component failures.

Asaadi et al. [START_REF] Asaadi | Towards quantification of assurance for learning-enabled components[END_REF] propose a method to quantify (g) assurance measures online, during run-time, by using Gaussian processes. They suggest that such quantification of the use case considered could consist of two aspects (i) identification of relevant dependability (e.g. safety) attributes, and (ii) quantification of these attributes and the associated uncertainty of that quantification. They propose to use the output of the quantified assurance measure to dynamically check the validity of the assurance case and thus support dynamic assurance cases.

D. Product-Line Contract Based Design

Nešić et al. [START_REF] Nešić | Product-line assurance cases from contract-based design[END_REF] discuss assurance, in the context of Product-Lines (PL) in system development, based on CBD. The purpose is to handle system variants (c) at design-time and create valid assurance cases for all of them. This is done by extending the model for CBD (e.g. [START_REF] Benveniste | Contracts for system design[END_REF]) to define conditions under which all system variants can be shown to fulfil the specified requirements. These conditions are used to define an assurance case pattern that also enable step-wise assurance case creation. Further, they believe that it is feasible to express general PLs according to the proposed CBD model. Using this model of the system in the design phase would yield early insights into the system and what needs to be addressed in order for the assurance pattern to be completed and a valid assurance case compiled. The work addresses similar problems as those discussed by Schneider and Trapp (ConSerts) [START_REF] Schneider | Conditional safety certification of open adaptive systems[END_REF], but in slightly different contexts and also focus on different main challenges. Where [START_REF] Nešić | Product-line assurance cases from contract-based design[END_REF] address the combinatorial complexity of configurations of different variants across a PL, [START_REF] Schneider | Conditional safety certification of open adaptive systems[END_REF] address the challenge where evidence of the system configuration and the components operating environments cannot be obtained prior to run-time. Both the certificates in ConSert and the contract structure of PL-CBD are defined during design-time. ConSerts are however evaluated in their present context during run-time and the demands are checked using the currently available run-time evidence.

It seems possible to adapt and configure the approach from [START_REF] Nešić | Product-line assurance cases from contract-based design[END_REF] to also solve the challenges of run-time evidence addressed by [START_REF] Schneider | Conditional safety certification of open adaptive systems[END_REF]. All possible system configurations (including service configurations) and operational contexts need to be described according to the PL CBD structure and further analysed according to the proposed criteria in order to assert the fulfilment of the requirements. However, even though the example in [START_REF] Schneider | Conditional safety certification of open adaptive systems[END_REF] would be possible to fit into the framework of [START_REF] Nešić | Product-line assurance cases from contract-based design[END_REF] (since the parameters considered only pertain to the system configuration and that this number of configurations clearly is finite), cases where the evidence is only obtainable during run-time (e.g. pertaining to external environment) might not be possible to frame in the PL CBD framework. Especially, the complexity of considering all possible system configurations with all possible environmental contexts would lead to a combinatorial explosion, which in general would result in the PL CBD approach being infeasible to provide completeness of the assurance (cf. Scenario-based V&V). In such a context, delaying the certification until run-time when the specific combination of parameters has been significantly reduced would perhaps yield a better confidence in the provided assurance, thus playing in favour of the ConSert approach of [START_REF] Schneider | Conditional safety certification of open adaptive systems[END_REF]. We also note that it is unclear how stochasticity and uncertainty is addressed in the two approaches.

E. Continuous Assurance Cases

Warg et al. [START_REF] Warg | Continuous deployment for dependable systems with continuous assurance cases[END_REF] propose a method for updating the assurance case for a function in step with changes in an agile/iterative development cycle. The motivation is to enable steady feature growth after deployment, e.g. being able to expand the ODD or improve performance for an ADS (e.g. due to better understanding through increased data collection). The method include using assurance case fragments for individual components which are then aggregated using safety contracts. Updates of the assurance case are planned for, and performed, in step with the feature development, and the assurance case is version managed with the product. This method has yet to be proven in a use-case and lacks tooling. However, it is based on the criteria for modularity (e), frequent update (a) and use of operational data (b), and we believe it can be a useful base for adding parts of other methods to eventually fulfill all criteria.

IV. CONCLUSIONS & FUTURE WORK

In this paper, we have proposed criteria that we believe are necessary for effective, efficient and flexible development and assurance of ADSs. Some existing techniques that may contribute to fulfilling these criteria are discussed -where a more systematic survey of the state-of-the-art remains as future work to create a complete view of existing work. An observation is that there seems to be a significant gap between state-of-the-art in research and state-of-practice. There are likely several reasons for this, and safety assurance for ADSs lack maturity in general. However, in our future work we would like to better understand the reason behind, and be able to address, this gap.

One initial impression is that there is a lack of tools compatible with our proposed criteria, at least widely deployed tools. Safety-contract tools such as CHESS [START_REF] Cicchetti | CHESS: a model-driven engineering tool environment for aiding the development of complex industrial systems[END_REF] and CHASE [START_REF] Nuzzo | CHASE: Contract-based requirement engineering for cyber-physical system design[END_REF] exist, but do not seem well suited, especially considering criteria (a)-(c) and (f). Since both are based on formal specification, which require significant expert skills, it may also be difficult to achieve wide adaptation in an agile organization. However, a more in-depth investigation of tools in light of the proposed criteria remains as future work.

We intend to improve the continuous assurance approach [START_REF] Warg | Continuous deployment for dependable systems with continuous assurance cases[END_REF], aiming to fill the remaining gaps identified in the assurance method criteria table. To that end, one task will be a deeper study of the methods mentioned in this paper, as well as other works related to ADS safety assurance, aiming to find additional elements to incorporate. Looking at the applicability of the ConSert approach for complex systems such as ADSs and the possibility to merge the runtime flexibility of this approach with the elements of the continuous assurance approach seems to be a promising start. Finally, answering the question: "How to compose contracts to capture the quantitative risk norm and relay this information throughout the ADS?", will be central in order to connect a contract-based assurance method to the risk norm at vehicle level.

  The research has been supported by the Strategic vehicle research and innovation (FFI) programme in Sweden via the SALIENCE4CAV project (ref 2020-02946) and the Wallenberg Al, Autonomous Systems and Software Program (WASP) funded by the Knut and Alice Wallenberg Foundation.

TABLE I SAFETY

 I ASSURANCE METHODS MAPPED TO ASSURANCE METHOD CRITERIA.

	Assurance method	Freq. upd. Op. data	Assurance method criteria (a) to (g) Monitor Variants Modular Self-adapt. Quant. AC	References
	Safety-contract based design					X		[5], [11]-[14]
	Conditional safety certificates (ConSert)			(X) [15]	X	X	X	X	[15], [16]
	Dynamic assurance cases			X			(X) [17]	X	[17]-[20]
	Product-line contract based design				X	X		[21]
	Continuous assurance cases	X	X			X		[10]