AS verification assurance
Objectives
- Generate evidence to demonstrate that the safety requirements specified for the AS are satisfied
- Justify the sufficiency of the verification activities
- Create the AS verification argument
Inputs to the stage
- [B] : Operational domain model
- [D] : Autonomous capabilities definition
- [E] : Operating scenarios definition
- [L] : Safe operating concept (SOC)
- [Q] : Safety requirements for tier n
- [UU] : AS verification argument pattern
Outputs of the stage
- [RR] : Verification strategy
- [SS] : AS verification log
- [TT] : Verification results
- [VV] : AS verification argument
Description of the stage
The purpose of verification is to generate evidence to demonstrate that the safety requirements specified for the AS are satisfied within the defined operating context. Verification may be carried out for different tiers of the system decomposition. For example, as illustrated in Figure 30 above, this may involve performing verification of the requirements on individual components of the AS and on the sub‐systems created through integrating components together, as well as verification of the AS platform as a whole. At each tier, the verification is performed with respect to the safety requirements defined for that particular tier.
Note 30 - Challenges to testing AS
In many regards, the approaches to verification of AS are no different from those used for traditional systems. However, as the behaviour of AS is often less bounded than for traditional systems, this can give rise to particular challenges, particularly when verifying AS that operate in complex environments. In [43] the following non‐exhaustive list of challenges to testing AS are identified:
- Unpredictable environment: This unpredictability adds uncertainties to testing as the AS can run into environmental variables that may have been unknown during design.
- System and scenario complexity: It is unclear how to define scenarios that include all features involved in the operational environment and the system itself and how to check whether the scenarios used for testing reflect the actual situations encountered.
- Data accessibility: To be able to test the systems, good quality data is required. This data can be difficult and costly to collect, interpret and validate for AS.
- Missing standards and guidelines: No accepted standards and guidelines are established for testing of AS. This makes determining the sufficiency of the testing activities used more difficult, and harder to justify.
Note 31 - Verification of low-level tiers
For low‐level tiers, such as individual components that use particular technology, particular approaches may be required for which further, more detailed guidance is required (such as that provided for components that use machine learning in [20]).
