Navigation
Minimap of introduction diagram
Minimap of stage diagram
View Diagram

SACE outline

Example 1 - Delivery robot
Example 2 - Self‐driving car
Note 1 - Defining capabilities
Note 2 - Iterative process
AS concept definition [A]

Example 3 - Autonomous cars
Example 4 - Office environment
Example 5 - Defining people
Note 3 - Challenges when defining an ODM

Example 6 - Office environment
Example 7 - Autonomous vehicle scenario
Note 4 - Scenes and scenarios
Note 5 - Resilience

AS operating context assurance argument pattern [G]

Example 8 - ODM and identified interactions
Note 8 - Mission and non-mission interactions

Example 9 - Decision point for an autonomous robot
Example 10 - Enumerated situations for an autonomous robot
Example 11 - Autonomous car turning at a roundabout
Example 12 - Autonomous insulin pump
Example 13 - Autonomous robot
Example 14 - Autonomous car
Example 15 - Autonomous insulin pump

Example 16 - Hazardous scenarios
Note 9 - System environmental belief state

AS hazardous scenarios assurance case pattern [I]

Example 17 - Autonomous car braking requirement
Example 18 - SOC for autonomous car on construction site
Example 19 - Autonomous insulin infusion pump
Example 20 - Autonomous passenger shuttle
Example 21 - Autonomous insulin infusion pump
Example 22 - Autonomous car in emergency roadworks
Note 10 - Requirements syntax
Note 11 - System-level safety requirements
Note 12 - Sufficient mitigation for hazardous scenarios
Definition of sufficiently safe [K]

Note 13 - Simulation

SOC argument pattern [N]

Example 24 - Different tiers of an autonomous system
Note 14 - Intent of the safety requirements
Note 15 - Decomposing safety requirements
Note 16 - Link between safety requirements and the design process
Note 17 - Machine learning

Note 18 - Relationships between safety requirements

Safety requirements argument pattern [S]

Note 19 - Definition of system architecture
Note 20 - Logical and physical structure of the system
Note 21 - Diversity in architecture redundancy
Note 22 - Fault tolerance approaches
Design process for tier n [X]

Note 23 - Independent reviewers

AS design assurance argument pattern [U]

Example 25 - Autonomous passenger shuttle
Note 24 - HAZOP analysis

Example 26 - Sensors for autonomous robot

AS hazardous failures argument pattern [DD]

Example 29 - Drone in severe weather conditions
Description of key features of environment outside ODM [FF]

Example 30 - Autonomous car leaving a motorway
Example 31 - Car's rainfall sensor
Note 27 - Challenges to recognising the ODM boundary

Example 32
ODM transition model [JJ]

Example 33 - Satellite ‘safe modes’
Note 28 - Handover
Stakeholder risk acceptance definition [LL]

AS Hazardous Scenarios Assurance Case Pattern PP [PP]

AS Verification Plan

The verification plan shall explicitly detail the verification activities as well as documenting the rationale for those activities. The plan is a more concrete implementation of the strategy, defining what should be done (e.g. specific tests) and how (e.g. environment, tools). Some of the key considerations that should be included in the verification log are given below.

Testing Details of the test cases shall be provided along with the required result for that test case. A justification for the sufficiency of the coverage that the test cases provide shall be included in the verification plan. For AS the coverage should in particular consider:

  • Safety requirements ‐ Are there test cases relating to each of the safety requirements defined for the relevant tier?
  • ODM ‐ Are there a sufficient range of test cases for each of the relevant ODM features? Are a sufficient range of combinations of ODM features represented by the test cases?
  • Operating Scenarios ‐ Do the test cases provide sufficient coverage of the possible operating scenarios of the AS? [44] provides a survey of the coverage criteria that have been proposed for verification of autonomous vehicles and possible techniques for maximizing coverage.
  • Edge cases ‐ Do the test cases include sufficient examples of edge cases (low probability, hard to predict events or situations with high potential safety impact) to which the AS may be exposed during operation?

Details of the test environment shall be included in the verification plan. A justification shall also be provided that the test environment is sufficiently representative of the real operating domain of the AS. This justification is required in order to provide confidence that the results obtained for the test cases for the AS in operation would match the results observed in the test environment. This is particularly important for simulation‐based testing, where justification must be provided that the simulation tools and models are sufficiently valid to support the claims made as a result of the tests.

Formal verification The formal properties shall be specified in the verification plan along with the rationale for the specification and a justification that the specified properties are equivalent to the relevant safety requirements. The formal models that are used for verification shall be documented in the verification plan along with a justification for all assumptions and abstractions made in the model, both with respect to the AS itself, and with respect to the operating environment.

Continue to: Activity 30. Verify AS
  • Assuring Autonomy logo
  • Lloyd's Register Foundation Logo
  • University of York logo

Our site depends on cookies to provide our service to you. If you continue to use this site we will assume that you are happy with that. View our privacy policy.