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 argument pattern

The argument pattern relating to this stage is shown in Figure 31 below and key elements from the pattern are described in the following sections.

Figure 31: [UU]: Argument pattern for AS verification

This argument is created for each tier, to demonstrate that the verification evidence that is provided for that tier is sufficient to show that the safety requirements defined at that tier are satisfied.

The claim is supported by making an argument over the chosen verification strategy that is defined in [RR]. A justification for why the defined strategy has been chosen must also be provided (J8.1). The strategy may involve testing, formal verification, or some combination of these approaches. Where testing is used, claim G8.2 must be instantiated. Where formal verification is used, claim G8.6 must be instantiated.

Where testing is being used, for each of the defined safety requirements it must be demonstrated that the testing undertaken demonstrates that the requirement is satisfied. To support this claim it is necessary to show that the relevant test cases are passed (G8.3), that those test cases are sufficient, given the operating context of the AS, to demonstrate that the requirement is satisfied (G8.4), and that any test platform that was used to perform the tests is sufficiently representative (G8.5). The verification log ([SS]) is used as evidence to support these claims.

Where formal verification is being used, for each of the defined safety requirements it must be demonstrated that the verification undertaken demonstrates that the requirement is satisfied. To support this claim it is necessary to show that the formally specified properties have been proven to be satisfied (G8.7), and that those specified properties are sufficiently representative of the safety requirement in the AS operating context (G8.8).

To demonstrate that the formally specified properties are satisfied, the results of the formal analysis ([TT]) are used as evidence (Sn8.4). It is also necessary however to demonstrate that the formal model that is used to undertake the analysis is an accurate reflection of the real AS in its operating environment. This claim is made at G8.10 and is supported by evidence from the verification log ([SS]).

Continue to: Stage 9. Afterword - authors and thanks
  • 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.