- Showcase the benefits of applying STPA to AED and the lessons learned regarding the analysis process and documentation.
- STPA was useful in elucidating and characterizing these problems, including language barrier, rescuer stress, coordination among multiple bystander rescuers, etc.
- The STPA analysis decisions include choice of hazard statements, the rationale for arranging the elements in the control structure, the identification of unsafe control actions and causal scenarios, and results organization.
- The presentation concludes with discussion of potential AI requirements for designing next generation AEDs.

-Introduces Systems-Theoretic Concept Design, an extension of STAMP to build early concepts for novel systems in aerospace and defense
-Existing models for early concepts are usually built using the DoDAF OV-1, which in reality contains very little information nor is it effective at bringing stakeholders together to consider a new system's intent, assumptions for its development, or constraints in the solution space
-Defense Systems are employed in a Portfolio-of-Systems, and STCD is a process to generate a first design artifact for a new system that captures this particular context

- Safety Analysis Overview: Approach, Project Management, Findings, Implementation Plans
- Experience with CAST Application: Application Specifics, Comparison with Traditional RCA, Complements with Human Factors Methods, Timeline, Lessons Learned/Takeaways, Future Applications
- Key Findings:
-- CAST can generate unique findings outside of traditional RCA, SEIPS PETT Scan,
etc.
-- Control structures are effective models to visualize systems and identify
areas of focus and improvement
-- CAST is a valuable and feasible tool to be used in safety analyses of health
systems

- We demonstrate an application of STPA to a complex, sociotechnical system
- We identify systemic factors that underly adverse events involving laboratory medicine
– We propose recommendations to address the systemic factors

This talk investigates the utility of STPA for analyzing safety before flight testing an Uncrewed Air Vehicle (UAV) controlled by a neural network-based flight autonomy software. The host UAV included various control regimes and handoffs over the course of a sortie including human control, traditional autopilot, and an artificial intelligence autonomy software trained using Deep Reinforcement Learning (DRL) machine learning techniques. The flight test operational environment included flight in both civil and restricted airspace, and at least one nearby crewed chase aircraft to observe the UAV in flight. STPA was applied after traditional airworthiness and safety assessment processes but before flight test to identify and mitigate potential new hazards associated with the UAV technology and its operation.

Discussion of questions and comments submitted live by attendees. This is your chance to ask MIT or any of the presenters your challenging questions. Get expert answers on controversial topics, like what limits should be put on the use of probabilities, perspectives about Agile, what to do about a challenging pitfall, and other topics.

STPA was applied to human interaction with a rotorcraft flight control system. The findings identified hazardous functionality outside of failure condition assessment alone. STPA identified previously overlooked causes including:
- Unintuitive design
- Missing functionality and feedback
- Implicit and flawed assumptions about operator beliefs

During our STPA project for future aircraft design, we used a diverse team which included test pilots, engineers and designers to work on the project. Pilot involvement has been a unique and extremely helpful addition: they are inherently “systems thinkers” and fantastic at supporting all phases of the STPA process. We used STPA in the concept development phase to uncover unknown unknowns, before an aircraft architecture was developed, allowing us to use the control structure as a basis for future aircraft architecture. Our biggest finding so far has been that STPA allowed us to develop a set of requirements where 90% of them were either improving a previous set or were new requirements

The author would like to present a recent application of STPA to model the structure of a government-funded project related to the development of EVs. The analysed system involves a diverse range of stakeholders, including regulators and funding authorities from the Government, certification agencies related to vehicle type approval and ISO26262 certification, funded stakeholders involving the EV OEM and its tier 1 and tier 2 suppliers, vendors of relevant parts, and the public.
Motivations of the application:
1. To provide project stakeholders insights into the project structure.
2. To identify existing or potential flaws of the project structure.
3. To create a blame-free working culture.

This presentation will describe how STPA is being used to design resilient, human-centred systems for the GB rail industry, showing that by integrating STPA with human factors analysis and cognitive systems engineering it’s possible to create cost-effective approaches to enhance safety and performance in complex safety-critical environments. The talk will outline:
-The theoretical foundations that underpin the analysis and design of distributed human-machine systems.
-Real-world examples of STPA applications.
-How STPA has helped to identify i) hidden socio-technical system risks and ii) opportunities to tackle problems of communication, coordination and control.

This talk presents lessons learned from teaching STPA at Google:
- Traditional STPA examples of physical systems are not easily relatable for software developers, and can lead to skepticism regarding STPA’s value
- We achieved higher learner engagement by giving examples of STPA applied to actual Google infrastructure and software
- We increased interest in STPA by emphasizing STPA’s ability to analyze feedback paths, something not addressed by other software design/risk analysis methodologies.
- To accommodate busy schedules, we are pursuing a tiered approach with initial, short tutorials to capture interest, then a multi-day workshop to practice applying STPA on a real system.

- Leveraging STPA to enable effective collaboration on safety case development between OEM and SEooC ADAS stack supplier for complex driving automation features.
- STPA supports OEM’s validity of SEooC assumptions.
- Integrating STPA into existing OEM safety process.
- Practical application demonstrates the use of abbreviated STPA method through a case study on an ADAS SEooC system integrated into an OEM vehicle.
Acronymns: ADAS: Advanced Driver-Assistance Systems; Item: System at the vehicle level; OEM: Original Equipment Manufacturer; SEooC: Safety Element out of Context; SOTIF: Safety of the Intended Functionality

Discussion of questions and comments submitted live by attendees. This is your chance to ask MIT or any of the presenters your challenging questions. Get expert answers on controversial topics, like what limits should be put on the use of probabilities, perspectives about Agile, what to do about a challenging pitfall, and other topics.

Expansion of STPA process for:
- systematically identifying potential conceptional architecture candidates
- and decision for optimal conceptional architecture
- shown by a simplified pedestrian collision avoindance example.

- Value-Based Engineering (VBE) integrates ethical values into system design, supported by the IEEE 7000 standard
- STPA was used as a tool to fulfill the standard's requirements
- A charging app example was used to illustrate the approach
- The study shows STPA's suitability for achieving VBE goals
- Future work will focus on practical application with the necessary personnel to further validate and refine the methodology

- A case study demonstrating application of STPA techniques to assess safety of electric vehicles
- Introducing a method to complement the STPA results for prioritizing the causes and to derive cause-effect relations
- Results identifies causal paths to the hazards and estimates unique KPIs for prioritizing causes

This talk will present the experience of applying the STPA in a military datalink System of Systems, focusing on a human factors approach;
The discussion covers:
• Dissemination of STPA inside the company and the effort necessary to perform the methodology;
• Complementation of traditional human factors analysis focusing on showing compliance with MIL-STD-561C;
• Advantages of Causal Scenarios generation based on Engineering for Humans Extension;
Since the analysis is confidential, only illustrative examples will be shown.

The main goal of this case study is to establish provisional targets for thrust responsiveness thrust response targets, based on safety constraints identified during the application of STAMP process.
The methodology selected to perform this case study will obey the following sequence:
i) Survey airworthiness requirements related to thrust responsiveness;
ii) Apply STAMP process to identify safety constrains;
iii) Definition of thrust response safety requirements.

The Civil Aviation Authority (CAA) aimed to modernize audit processes by improving data and information exchange with overseen organizations to enhance safety evaluations and reduce subjectivity. This shift supports the transition from compliance- to performance-based oversight. The STAMP approach was used to create performance-based audit questions linked to regulatory requirements and tested in real audits. Three CAA departments joined in testing the approach, with two finding it beneficial for audits, while the third, focused on technical audits, remained unconvinced. This method supports detailed, context-rich inquiries, enhancing the understanding of processes and safety performance.

Discussion of questions and comments submitted live by attendees. This is your chance to ask MIT or any of the presenters your challenging questions. Get expert answers on controversial topics, like what limits should be put on the use of probabilities, perspectives about Agile, what to do about a challenging pitfall, and other topics.

This presentation shares opportunities, challenges and lessons learned in integrating STPA as part of Europe’s Rail landscape.
Topics include:
- Strategies to integrate exisiting requirements into the STPA process
- Linking STPA results to solution concepts
- Validating assumptions

-Insights and lessons learned from applying STPA.
-Benefits and current limitations of applying STPA.
-Evaluation and comparative studies with traditional approaches.
-I recommend system designers to use STPA to strengthen the safety and reliability of systems.

In this session, we will take you on our STPA adoption journey at Google. We'll cover:
- The big picture: Adoption of STPA at Google
- 3 adoption challenges
- Deep-dive: Google Maps data product risks

- An STPA was conducted for an offshore oil well during production phase and satisfactory results were obtained.
- It was also possible to identify the impact of the granularity of the analysis on the results (high-level and high-detailing).
- A comparison of STPA results and a Fault Tree Analysis pointed out the significant contributions the STPA can bring to the safety analysis, emphasising the differences in how each technique deals with component failures.

This talk will introduce MicroSTAMP, a free and open-source tool designed to support STPA using a microservices-based architecture. We will explore the key features that make MicroSTAMP a valuable resource for analysts conducting STPA, focusing on its flexibility, scalability, and the APIs it provides to support each step of the STPA. Additionally, the talk will cover the advantages and disadvantages of using a microservices architecture in the context of STPA applications, including the possibility of integration with other tools and the challenges of managing multiple microservices and databases.

Discussion of questions and comments submitted live by attendees. This is your chance to ask MIT or any of the presenters your challenging questions. Get expert answers on controversial topics, like what limits should be put on the use of probabilities, perspectives about Agile, what to do about a challenging pitfall, and other topics.