The aim of AMLAS is to provide guidance on how to systematically integrate safety assurance into the development of ML components. A primary outcome of this integration is an explicit and structured safety case. More specifically, AMLAS offers a set of argument patterns and the underlying assurance activities, that can be instantiated in order to develop the ML safety cases.
The scope of AMLAS is limited to the ML component. As such, it should not be used in isolation from other standards and guidelines that specify best practices in safety‐critical systems (e.g. ARP4754A [3]), domain‐specific requirements (e.g. CONSORT‐AI [44] or ISO/PAS 21448 [31]) or safe autonomy considerations (e.g. UL4000 [41] or SCSC‐153A [49]).
For example, the system‐level safety requirements, including acceptable risk targets, are a fundamental input to the AMLAS process. These requirements are expected to be generated by domain experts or derived from the relevant regulatory requirements.
AMLAS has a primary focus on off‐line supervised learning. Off‐line supervised learning, particularly applied to classification tasks, is currently the predominant application of ML for autonomous systems. Other types of ML such as reinforcement learning may also benefit from this guidance, particularly with regard to safety requirements and data management.
This guidance is aimed at
The intended user of AMLAS is expected to have a basic understanding of machine learning, safety engineering and autonomous systems. Interested readers are encouraged to consult these practical and introductory resources:
In AMLAS, the argument patterns are represented using the Goal Structuring Notation (GSN) [25]. GSN is a graphical notation for explicitly capturing safety arguments. It is widely used in many industries for documenting safety cases. For a detailed description of the notation, the reader is advised to consult the publicly available GSN standard [25].
Throughout the guidance, the use of ”shall” indicates a required element of the guidance. Information marked as a “NOTE” or “EXAMPLE” is only used for clarification of the associated activities. A “NOTE” provides additional information, for clarification or advice purposes. An “EXAMPLE” is used to illustrate a particular point that is specific to a domain or technology. An example presented in this document is not meant to be exhaustive.
In the AMLAS process diagrams, rectangles represent activities. Document symbols represent input or output artefacts. Each document symbol has a unique ID (top left) that is used to refer to the artefact in the guidance text or the argument pattern (e.g. [A] is a reference to artefact A).