SACE process

Creating a compelling safety case for an AS of the form discussed previously requires that certain activities are undertaken and that certain artefacts are generated. The SACE process describes the required activities and artefacts in order to achieve this. SACE is split into a number of stages, each of which defines a set of activities and artefacts. Each stage corresponds to one of the autonomy-related aspects of the system safety case as discussed previously and indicated in Figures 2 and 3 as coloured elements. Figure 4 provides an overview of the SACE process indicating each of these stages.

As discussed, an established system safety process should run in parallel to SACE as well as the system development itself. Like these processes, the SACE process is iterative, as indicated by the feedback loop in Figure 4. Each stage of the SACE process is linked to the ‘Feedback and Iterate’ thread and could trigger the need to reconsider information generated or consumed by other stages. This is also necessary because of the interdependencies between the different stages, e.g. an activity in one stage might use artefacts produced by another activity in a previous stage.

The stages of SACE may therefore be performed multiple times throughout the development of the AS, reflecting the iterative nature of AS development processes. For example, the design assurance activities may identify hazards that were not apparent during the initial hazard identification stage. This would require that the hazard identification stage be revisited to update and assure the hazard identification. This would then require that later stages such as the safety requirements assurance are revisited.

In this guidance, each SACE stage is structured as follows:

• Objectives of the stage.
• Inputs to, and outputs from, the stage.
• Description of the stage, including development and assurance activities and associated assurance artefacts and safety argument pattern.

The description of each stage details the activities to be undertaken and the artefacts produced or required by the activities. Note that detailed guidance is provided for some artefacts, whereas others are simply specified as the documented outputs of particular activities. The description also discusses common issues and misunderstandings relating to each activity; these are generally provided as notes or examples. Importantly, each stage concludes with an activity for instantiating a safety argument pattern based on the artefacts and evidence generated in the stage.