Define and validate the operating scenarios
An operating scenario of an AS represents a particular set of actions and events that the AS may undertake in a defined environment situation. We adopt the characterisation used in [10] as a description of the AS, its activities and/or goals, its static environment, and its dynamic environment.
Note 4 - Scenes and scenarios
The following distinction is often made between “scenes” and “scenarios” [46]:
- A scene describes a snapshot of the environment including the scenery and dynamic elements, as well as all actors’ and observers’ self‐representations, and the relationships among those entities. Scene descriptions will inevitably be incomplete and vary from one or several observers’ points of view.
- A scenario describes the temporal development between several scenes in a sequence. Every scenario starts with an initial scene, and the temporal development is characterised by a set of actions and events.
Example 6 - Office environment
An example of a scene could be a typical office environment, with office furniture, artificial lighting, and an autonomous robot in a corridor that is also used by human staff members. A scenario could develop where an autonomous robot and a human are approaching a right‐angle in a corridor from opposite directions.
Example 7 - Autonomous vehicle scenario Automotive
Figures 8 and 9, taken from [10] provide an example of a scenario description for an autonomous vehicle.
Figure 8: Schematic overview of the scenario of both an autonomous vehicle and a pedestrian approaching a non‐signalised pedestrian crossing (from [10]).
Figure 9: A qualitative description of the same scenario (from [10]).
It is crucial for safety assurance of the AS that the operating scenarios that are relevant to the AS within its defined ODM are identified as completely and correctly as possible. If we refer to Figure 6, we must identify the operating scenarios present in the area inside the orange boundary defining the scope of the ODM. The green area in the diagram represents all of the identified scenarios within this area. It is not possible for a complex, open environment, such as an urban street, to provide an exhaustive detailed specification of the operating scenarios, since the set of scenarios is simply too large.
Where operating scenarios exist within the scope of the ODM, but are not correctly identified, these could pose a safety risk to the AS since the scenario could be hazardous, but would not be assessed as part of the safety assurance process and therefore no mitigations put in place. This is represented by the red area in Figure 6. It is very important therefore for safety assurance to have confidence that this area is as small as possible by ensuring the operating scenarios are sufficiently well defined.
Note 5 - Resilience
It is partly as a result of the possible existence of the red region in Figure 6 that resilience is such an important requirement when designing ASs; these unanticipated operating scenarios require that the system is able to adapt in a safe manner to unplanned events. This is discussed in more detail at Stage 6.
The operating scenario descriptions shall be validated to provide evidence that they are sufficiently complete and correct. Evidence can be provided based upon review of the scenario specification. A rigorous specification to a defined format makes the scenarios more amenable to review and reduces ambiguity. It is important that review is carried out by a range of experienced stakeholders. Providing simulations of the defined scenarios may help to ensure the reviewers have a correct understanding of the scenarios. The defined scenarios can also be checked against collected field data from AS in operation to ensure that all encountered scenarios are captured in the operating scenario specification. The results of the data validation activity shall be explicitly documented ([F]).
The definition of scenarios should be an iterative process, where the scenarios are refined based on increased understanding of the relevant and important aspects of the scenario space. This refinement may be informed by the outcome of the validation activities described above, particularly the results of simulation and field‐based validation tests.
