Abstract

As far as safety is concerned, resorting to a so-called “accident model” (i.e., an explanatory conceptual model of accident mechanisms) is necessary since it is supposed to bring insights with a formal structure into how accidents occur, how they should be analysed and how they can be prevented or mitigated.

The general approach we are describing in this paper is STAMP (Systems-Theoretic Accident Model and Processes), an accident causality model based on control theory and systems theory (Leveson, 2011). STAMP integrates into engineering safety analysis causal factors such as software, human factors, new technologies, social and organization structures, and safety culture. It is designed to address complex systems. The method behind the approach is STPA (Systems-Theoretic Process Analysis), the hazard operational analysis technique (Leveson and Thomas, 2013, 2018). STAMP and STPA have been widely disseminated and now receive more and more attention and interest, especially when new technologies and complex systems are considered. 

STPA proposes a stepwise methodological process. Once the definitions of accidents / hazards / safety constraints are made, a control structure of the whole system must be described (including relationships, i.e., control actions and information feedback, between all components (or “controllers”) of the system). Every controller imposes control processes and safety constraints on the level underneath. Every controller has a process model that includes the understanding and representations that controllers have of the controlled process. They are kept up to date through feedback loops. Accidents occur when the system gets into a hazardous state due to the inadequate enforcement of safety constraints on the system behavior. 

An example of control structure at the micro level is proposed in the paper as for interactions between vehicles, users and environment. An example of control at a higher or macro level would show relationships (control and feedback) between all stakeholders (standardization and regulation bodies, European Commission, ministries, insurance companies, road vehicle industry, driving school, hospitals, road operators, etc.

The next step consists of identifying potential unsafe actions from one processor to another. This is a paramount step since safety requirements, are just mirrors of the unsafe control actions. Then, once a preliminary list of requirements is achieved, the next step consists of identifying scenarios (or control flaws) that could lead to unsafe control actions. Leveson and Thomas (2018) give guidance on how the scenarios could be generated. Once the scenarios are determined, the safety requirements can be refined and enhanced. Generally, this refinement ends up increasing the number of initial requirements and making them more precise and accurate.

The paper proposes to apply STPA to the safety of automated vehicles. A list of 63

63 macro safety requirements is proposed that can be used both for the design of such vehicles and eventually the analysis of crashes involving them by simply identify what safety requirements were not, or partially met.