Navigation
Minimap of introduction diagram
Minimap of stage diagram
View Diagram

AMLAS outline

Example 5 - Defining acceptable risk level
Example 6 - Translating safety requirements
Example 7 - Performance and robustness
Note 5 - Semantic gap
Note 6 - Under‐specificity
Note 7 - Safety criticality
Note 8 - Performance and robustness
Note 9 - Measurable features
Note 10 - Overall performance
Note 11 - Dimensions of variation
Note 12 - Tolerable risk

ML safety requirements argument pattern [I]

Data requirements [L]
Data requirements justification report [M]

Example 14 - Vehicle gathering video data
Example 15 - Handling missing data
Example 16 - Retinal scans
Example 17 - Augmenting the dataset
Example 18 - ML classifier for cancer
Note 16 - Justifying collected data
Note 17 - Rationale for existing data sources
Note 18 - Using simulators
Note 19 - Preprocessing of data
Note 20 - Labelling data
Note 21 - Combinations of variation
Data generation log [Q]

Example 19 - JAAD open dataset
Example 20 - Using US data in the UK
Example 21 - Data collection using controlled trials
Example 22 - Completeness of datasets
Example 23 - Occlusion
Note 22 - Financial and practical concerns
Note 23 - Simulation for data augmentation
Note 24 - Context-specific features
Note 25 - Dimensions of variability
Note 26 - Quantisation
Note 27 - Balance of datasets
Note 28 - Imbalanced dataset

ML data argument pattern [R]

Example 24 - Medical prognosis problems
Example 25 - Deep Neural Networks
Example 26 - Data samples from a photo simulator
Note 29 - Overfitting to training data
Note 30 - Trade-offs
Model development log [U]

Example 30 - Image analysis
Example 31 - Perception pipeline
Internal test results [X]

Model learning argument pattern [W]

Example 33 - Vehicle stopping distance
Example 34 - Contextual mutators
Example 35 - DeepMind retinal diagnosis system
Example 36 - Contextually meaningful values
Example 37 - Airborne collision avoidance system
Note 31 - Development and verification independence
Note 32 - Independence from verification data
Note 33 - Test completeness
Note 34 - Human evaluation
Note 35 - Point-wise robustness
ML verification evidence [Z]
Verification log [AA]

ML verification argument pattern [BB]

Example 42 - ML component for object classification
Example 43 - Pedestrian detection
Example 44 - Pedestrian detection - occlusion
Example 45 - Computational power
Example 46 - Pedestrian detection performance requirement
Note 37 - Violations of assumptions
Note 38 - Monitoring the system
Note 39 - Latency
Erroneous behaviour log [DD]

Operational scenarios [EE]

ML deployment argument pattern [GG]

System description

The allocation of system safety requirements to the ML component shall also consider the system architecture. The system to which the ML component shall be deployed and the system architecture shall be explicitly defined in Artefact [C]. This helps to ensure it is correctly accounted for when determining ML safety requirements.

Note 4 - Component relationships

The system description should include the inter‐relationship between the ML component and other system components including sensors and actuators. Figure 4 shows an example taken from [4] of the architecture for an autonomous taxiing capability in an unmanned aircraft system showing a Deep Convolutional Neural Network ML component in the context of other system components.

Artefact C Image

Figure 4: Example System Architecture (From [4])

Continue to: Artefact D. ML component description
  • 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.