Out of context operation assurance
Objectives
- Demonstrate that the AS will be aware if it is leaving the defined autonomous operating context
- Implement a strategy that ensures the AS remains sufficiently safe even if it leaves the defined autonomous operating context
- Instantiate the out of context operation assurance argument pattern
Inputs to the stage
- [B] : Operational domain model
- [FF] : Key features of environment outside ODM
- [JJ] : ODM transition model
- [LL] : Stakeholder risk acceptance definition
- [PP] : Out of context operation assurance argument pattern
Outputs of the stage
- [GG] : Out of context analysis report
- [HH] : Interpretation of ODM boundary
- [II] : ODM boundary assessment report
- [KK] : Transition assessment report
- [MM] : Outside ODM minimum risk strategy
- [NN] : Outside ODM strategy justification report
- [OO] : Outside ODM verification report
- [QQ] : Out of context operation assurance argument
Description of the stage
As shown in Figure 26 above, this stage consists of six activities that are performed to define and validate the safe out of context operation for an AS. The artefacts generated from this stage are used to instantiate the out of context operation assurance argument pattern as part of Activity 27. An AS may spend some time operating outside the defined ODM ([B]) whilst still be operating autonomously. This could be unsafe, since autonomous operation is only assured for safety within the defined ODM. There are several situations where operation outside the ODM may occur:
- The environment or context of the AS suddenly changes without warning (see example 28 below).
- The AS fails to recognise the boundary of the ODM (see example 29 in Activity 22).
- The boundary of the ODM is poorly defined, ambiguous or has dynamically changed. As in example 29, the transition between classes of weather conditions may for example be ambiguously defined.
- The AS does not recognise the boundary of the ODM within an acceptable period of time.
- The AS recognises the boundary but is unable to hand over to another function or an operator (either because none are available or the transition itself fails) and therefore continuation in autonomous mode is the safest option.
- The AS fails to transition out of autonomous mode quickly enough (this could take seconds or even minutes).
Example 27 - Autonomous car - flash floods Automotive
An autonomous road vehicle encounters flash flooding on the road. Such flood conditions are not within the ODM as they cannot be handled safely by the autonomous driving function. Since the flash flood conditions arise suddenly and unexpectedly it is not possible for the vehicle to anticipate and avoid these conditions.
Example 28 - Agricultural robot Agriculture
The ODM for an agricultural robot includes rain but not snow as the robot cannot operate safely in snowy conditions. During operation in heavy rain, the low temperature causes the rain to become sleet, followed by a transition to snow. The AS is unclear as to when sleet becomes snow and hence when it has moved outside of the ODM.
Note 25 - Time spent in autonomous mode
It is expected that time spent in autonomous mode outside the ODM should be limited, or indeed transient. Note that one option for dealing with outside ODM operating is to get back within the ODM as soon as possible.
