1 of 21

Enhancing Software Safety in System-Intensive Environments: Applying System-Theoretic Process Analysis (STPA)

Max Chopart

Open-Mic

24/10/24

2 of 21

STAMP (System-Theoretic Accident Model Process) – The Model

2

Controllers use a Process Model to determine control actions
Accidents often occur when the process model is incorrect
Four types of unsafe control actions:

Control commands required for safety are not given
Unsafe ones are given
Potentially safe commands but given too early, too late
Control action stops too soon or applied too long

3 of 21

STAMP (System-Theoretic Accident Model Process) – The Model

3

4 of 21

STPA (System-Theoretic Process Analysis) – The Methodology

4

Hazard identification method based on system engineering approach and control systems theory based on STAMP.
Full methodology described in the “STPA handbook”, N. Leveson, J. Thomas, 2018.
Top-down, system engineering technique that can be used at the very beginning of the system design process to influence and guide design decisions.

5 of 21

Goals of systemic approach: Case study – Lufthansa Flight 2904

A320-211

Software algorithm to make sure aircraft has landed to prevent reverse and spoilers while cruising:

Must be 6.3 tons on each main landing gear strut
Wheel must be spinning at least 130 km/h

A320-211

5

6 of 21

Goals of systemic approach: Case study – Lufthansa Flight 2904

Off-nominal landing condition at Warsaw in Sept 1993

Crosswind => One wheel lands first intentionally
Wet runway => Wheels hydroplane

Lufthansa Flight 2904 - Illustration of time elapsed between touchdown of the first main strut, the second and engagement of brakes.

6

7 of 21

Goals of systemic approach: Case Study – Lufthansa Flight 2904

1 Passenger died
Co-Pilot died
51 People were seriously injured

Lufthansa Flight 2904 crash

7

What failed?

8 of 21

Case study - AVA project

8

9 of 21

Step 1. Define the purpose of the analysis

9

10 of 21

Step 1. Define the purpose of the analysis

L-1: Loss of aircraft operational safety

L-2: Loss of data integrity

L-3: Loss of system confidentiality

L-4: Loss of decision-making efficiency

L-5: Loss of productivity

L-6: Loss of compliance (DO-178C)

H-1: Incorrect or incomplete data (L1, L2, L4, L5, L6)

H-2: Inaccurate or outdated records impair fault diagnosis and system reliability analysis (L1, L2, L4, L5, L6)

H-3: System outages or performance issues (L1, L2, L4, L5, L6)

H-4: Unauthorized users gain access to sensitive system data or functionality (L3)

10

L-1: Loss of aircraft operational safety due to undetected or misdiagnosed defects, resulting in operational failures during flight or maintenance.

L-2: Loss of data integrity within the web app, leading to the use of incorrect or outdated information for fault analysis and maintenance decisions.

L-3: Loss of system confidentiality due to unauthorized access to sensitive records or analytics, leading to a data breach or misuse of sensitive information.

L-4: Loss of decision-making efficiency due to delayed or incorrect data processing, leading to slow or misinformed decisions by maintenance teams.

L-5: Loss of productivity in the aircraft maintenance and defect reporting workflow, resulting in operational delays and inefficiencies.

L-6: Loss of compliance with regulatory or safety standards, leading to legal, financial, or reputational damage for the aircraft manufacturer.

11 of 21

Step 2. Model The Control Structure

11

12 of 21

Step 2. Model The Control Structure

12

13 of 21

Step 2. Model The Control Structure

13

14 of 21

Step 3. Identify the Unsafe Control Actions (UCA)

14

15 of 21

Step 3. Identify the Unsafe Control Actions (UCA)

15

16 of 21

Step 3. Identify the Unsafe Control Actions (UCA)

16

Control Action	Not providing causes hazard	Providing causes hazard	Too early, too late, or out of order	Stopped too soon or applied too long
Models FTA	UCA 1.1: Does not create fault tree, leading to a missed opportunity to identify system failures (H1, H2, H3)	UCA 1.2: FTA Tool creates a fault tree based on incorrect data, leading to incorrect fault diagnosis (H1, H2, H3)	N/A	UCA 1.3: Fault tree modeling is stopped before all inputs are considered, resulting in incomplete analysis (H1, H2, H3)
Sends records	UCA 2.1: Record Manager does not send defect records to AVA Analytics, delaying data analysis and maintenance (H1, H2, H3)	UCA 2.2: Record Manager sends incorrect or incomplete records to AVA Analytics leading to incorrect analysis (H1, H2, H3)	UCA 2.3: Records are sent too early, before validation is complete, leading to incorrect analysis (H1, H2, H3)	UCA 2.4: Record Manager stops sending records before the full dataset is sent, causing incomplete data processing (H1, H2, H3)

17 of 21

Step 4. Identify the Loss Scenarios

17

18 of 21

Step 4. Identify the Loss Scenarios

18

19 of 21

STPA is about abstraction - Zoom OUT !!!

19

20 of 21

Why do I need to apply STPA on AVA project?

DO-178C: Standard for ensuring the safety and reliability of software used in airborne systems, outlining requirements for software development and verification based on the criticality of the software. It defines a structured lifecycle process, including documentation and verification activities, to facilitate compliance with aviation regulations and certification.

20

21 of 21

Your thoughts about STPA in Software Development?

Extensively used at Google: http://psas.scripts.mit.edu/home/wp-content/uploads/2021/06/2021-06-23-1210__Falzone_Thomas.pdf
Helps identifying design flaws
Holistic analysis
Adresses Human Factor

Cannot be used to do Unit Testing
Time consuming
Need of domain experts

21