On STPA for Distributed Development of Safe Autonomous Driving: An Interview Study

TL;DR

STPA’s different guidelines for the automotive industry are compared and an approach to overcome the challenges of using STPA in a multilevel design context is proposed by conducting an interview study with automotive industry experts for the development of AD.

Abstract

Safety analysis is used to identify hazards and build knowledge during the design phase of safety-relevant functions. This is especially true for complex AI-enabled and software intensive systems such as Autonomous Drive (AD). System-Theoretic Process Analysis (STPA) is a novel method applied in safety-related fields like defense and aerospace, which is also becoming popular in the automotive industry. However, STPA assumes prerequisites that are not fully valid in the automotive system engineering with distributed system development and multi-abstraction design levels. This would inhibit software developers from using STPA to analyze their software as part of a bigger system, resulting in a lack of traceability. This can be seen as a maintainability challenge in continuous development and deployment (DevOps). In this paper, STPA's different guidelines for the automotive industry, e.g. J31887/ISO21448/STPA handbook, are firstly compared to assess their applicability to the distributed development of complex AI-enabled systems like AD. Further, an approach to overcome the challenges of using STPA in a multi-level design context is proposed. By conducting an interview study with automotive industry experts for the development of AD, the challenges are validated and the effectiveness of the proposed approach is evaluated.

Figures (2)

• Figure 1: Part A illustrates the multi-abstraction level architectural design, beginning from the stakeholders' level (level 0) and progressing to the most intricate building blocks of the system (level 2). Part C illustrates the fundamental control structure of STPA for analyzing the L2 subsystem, which should be carried out by assuming the blocks outside the scope of supply (inside red dotted lines). Part B introduces an alternative approach proposed in this study.
• Figure 2: Represents the information flow, traceability of requirements, unsafe control actions and causal factors between the results of our proposed approach in each abstraction level. It also shows the mapping between each step and relevant activities in ISO 21448 and ISO 26262. A hypothetical example is provided to better show the process of applying STPA and Sub-STPA.