AppSTPA

Safety is an emergent property of systems that states that the system is free from those conditions that can cause death, injury, illness, damage to/loss of equipment or property, or damage to the environment.

What is a hazard?

A hazard is any source of potential harm, danger, or adverse effect on health, safety, property, or the environment. Hazards may also be categorized as physical, chemical, biological, ergonomic, psychosocial, and natural. Hazard is also defined as a system’s state or set of conditions, together with a particular set of worst-case environmental conditions, that will lead to a loss. This loss can be related to safety, property, mission, environment, or other critical system objectives. Safety analysis aims to avoid hazardous situations.

Safety-critical systems are becoming more complex, they employ software, use physical and cybernetic components, and have more interactions (including hierarchical controllers). 

Additionally, these systems make intensive use of software, employ processors with increasing power, use different networks, operate with physical and cybernetic components, have more interactions (including hierarchical controls), and must follow the directives of certification bodies. 

There are several techniques for hazard analysis, and among them, there is the Systems-Theoretic Process Analysis (STPA). Some advantages of SPTA include:

• System-Theoretic Process Analysis (STPA) is a technique for hazard analysis that assists in identifying safety recommendations and constraints by considering that unsafe interactions among system components can cause accidents.

• Unlike traditional hazard analysis methods, which often focus on component failures, STPA considers complex interactions between system components, including software, human operators, and organizational factors.

• Can be used for any type of system, including social systems, providing a comprehensive view of complex human-system interactions that can lead to hazards.

• STPA is based on System Theory. Systems theory views a system as a complex set of interrelated components, where the behavior of the system as a whole emerges from the interactions among its parts. The focus is on understanding how these interactions and the overall structure of the system contribute to its behavior and lead to undesired outcomes or potential failures.

• STPA can be used in the concept stage of the safety-critical systems life cycle. 

STPA is generally employed in the concept stage of the safety-critical systems life cycle.  STPA is an iterative process conducted iteratively. STPA has four steps:

1. The first step defines the purpose of the system, identifying the system boundary, goals, losses, hazards, system-level constraints, and assumptions.

2. The second step is to model the control structure, creating a functional model that represents the system's components and their interactions, including human operators, software, hardware (e.g., controllers, actuators, controlled process, sensors, and links), and organizational elements. 

3. The third step identifies the unsafe control action (UCA). The UCA is a control action that leads to a loss in a particular context. 

4. The fourth step identifies the loss scenarios that, together with a causal factor, can lead to a UCA.

In general, the STPA analysis is lengthy and complex, however, it is claimed that STPA identifies more loss scenarios and recommendations when compared to other hazard analysis techniques, such as Fault Tree Analysis (FTA) and Failure Modes and Effects Analysis (FMEA). 

During the analysis process, it is common to miss some loss scenarios and safety recommendations. 

Few STPA-based tools allow systematic and automated analyses. We propose an ontology that represents the STPA analysis domain knowledge and we built an STPA ontology-based tool, called AppSTPA.

AppSTPA aids the analyst by providing a more systematic, automated, and guided analysis. 

Tool assistance and techniques are necessary to improve and ease the analyses. Most of the existing STPA tools are spreadsheet-based and do not provide the necessary guidance to the analyst through the analysis process. 

Guidance here is advice or information aimed at performing the STPA analyses, avoiding doubts, and helping the analyst to complete the analyses. 

There is a need for approaches that achieve better results, for instance, techniques that make the systems smarter or are able to automate the analysis.