Blog post: Bounding the open context. Specifying safety requirements for automated driving

The starting point for any safety-critical system development is always some form of analysis that derives a set of safety goals and requirements against which the system can be designed and evaluated. However, automated driving systems can be seen as “open context”. This means that they operate within an environment which cannot be fully specified at design time, either due to the inherent complexity and unpredictability of the environment or due to the manner in which the environment evolves. This leads to one of the biggest open questions in the safety assurance of automated driving:

How do we know that we have understood the environment well enough to identify all critical driving situations and to derive a complete set of safety requirements for the system?

For this reason the “domain analysis” phase of the framework I proposed here is an essential step towards developing a convincing assurance argument for the system.

Defining the desired behaviour

A systematic domain analysis forms the basis of an understanding of the environment in which the system should operate. More specifically, the goal of the domain analysis is to derive from the irreducibly complex environment a finite set of behavioural and performance-related safety requirements with clearly defined acceptance criteria. If this can be achieved, then we could apply standard safety engineering approaches to design and verify the system, and demonstrate an acceptable level of safety.

However, due to the complexity and ever-changing nature of the environment in which the vehicle operates, this understanding will inevitably never be complete and uncertainty regarding whether a complete and consistent set of safety requirements will remain.

The task then is to gain a sufficiently good understanding of the safety-relevant properties for a given Operational Design Domain (ODD) such that the system can be designed to meet the level of safety expected of it by legally binding regulations and society at large.

A scenario-based approach

One approach, proposed by the PEGASUS project is to structure the domain according to a set of driving scenarios grouped in line with a set of well-defined use cases. Each scenario is defined in terms of the following “layers”:

Each layer can be described according to a set of ontologies (e.g. to enumerate various weather conditions, road types etc.) and criticality indicators that define constraints to be met in the scenario, such as time-to-collision to the preceding vehicle.

A rule-based approach

An alternative method of specifying the desired behaviour of the vehicle is Responsibility-Sensitive Safety (RSS) proposed by MobileEye. In this approach, a set of general constraints on valid trajectories of the vehicle are formally specified as a set of rules that can be used during specification and monitoring of the vehicle behaviour.

The proposals made by the Pegasus project and MobileEye are not necessarily contradictory and indeed could be seen as complementary.

A hybrid approach

A hybrid scenario and rule-based approach to deriving a set of safety requirements could be summarised as follows:

1. Define a set of use cases that determine the purpose of the function being defined, including its operational domain and level of autonomy. A use case could be, for example, hands-free driving or keeping in lane on a segment of a highway between exits.
2. Identify relevant standards, legal requirements and social expectations to derive adequate performance targets and boundary constraints for the use cases (see blog post #2).
3. Identify a set of scenarios that could be encountered when performing each use case. Each scenario should be described in terms of actions, events and scenes which consist of dynamic elements, such as other traffic participants, scenery and environmental factors, and a self-representation. A scenario could be, for example, entering a tunnel under rainy conditions within a steady flow of traffic.
4. Identify and evaluate hazards for each scenario that could be caused by a failure of the systems within the vehicle, the function itself, the traffic situation or through interactions with the vehicle operator or other traffic participants (see blog post #3). An associated set of safety goals and fulfilment criteria should be defined to specify the necessary level of performance required for the scenario in order to reach the level of safety as defined in steps 1) and 2). This could include adopting formal rule-based approaches similar to RSS but tailored to the specific scenario including consideration of environmental factors that may impact the dynamic relations between objects (e.g. the braking distance due to wet roads).

The resulting set of scenario descriptions and associated safety requirements will form the basis of a detailed analysis of the system design to identify “triggering conditions” that could cause a violation of these safety goals and to derive appropriate mitigation measures.

The issue of unknown unknowns

Whilst systematic and incorporating different aspects of current best practice, the approach described so far has its focus on identifying and mitigating hazards associated with known properties of the environment and system.

It does not answer the problem that there may be situations or phenomena in the environment that we either cannot predict or are unaware that they may influence the behaviour of the vehicle. As Donald Rumsfeld famously put it, there are things that we don’t know that we don’t know, in other words, “unknown unknowns”. Continuous validation of the system will be required in order to iteratively refine the understanding of the system function and its environment. Hence the iterative nature of the framework as shown in the figure above.

Define a restricted set of scenarios that can be implemented with a high level of confidence. Iteratively refine and expand the context of the operational design domain as confidence increases through continuous validation.

Restrictions that would be applied in such an iterative approach relate to both the environment in which the system operates and to the scope of the function (e.g. level of automation) itself. However, each level of automation has its own specific set of safety challenges, such as vehicle-driver handover for Level 3. Also, adding too many restrictions on the set of conditions (e.g. weather) allowed for each scenario may add additional complexity and potential causes of failure such as the need to continuously measure lighting conditions and increasing the frequency of inherently risky vehicle-driver handover events.

Establishing a common understanding

The effort required to specify all possible scenarios and constraints for advanced use cases such as urban automated driving will be immense. Care must be taken to find the right level of abstractions to avoid infinitely detailed ontologies whilst missing key properties (or combinations thereof) that have a significant impact on the safety of the system.

Therefore, industry collaboration is required to derive a common understanding of the scenarios and safety properties to be considered when designing and assuring the safety of such systems. Indeed, both scenario and rule-based approaches are being introduced into various automated driving safety standards and regulations currently under development. These should be used in a next step to form the basis of standardised scenario and requirement specifications for typical use cases.

 

You can download a free introductory guide to assuring the safety of highly automated driving: essential reading for anyone working in the automotive field.

 

Dr Simon Burton
Director Vehicle Systems Safety
Robert Bosch GmbH

Simon is also a Programme Fellow on the Assuring Autonomy International Programme.

Read the blog on Medium