EP7 - STPA (System Theoretical Process Analysis) - Thoughts from Dr. Nancy Leveson (Part 1)
12:04 Share

Hello everyone, I'm Art Tomasetti here with the June edition of our podcast. In these challenging times, we continue with our monthly releases of the Flight Test Safety Fact Newsletter and this podcast. As these new challenges affect not only our work in flight tests, but our daily lives, we must continue to be vigilant, adaptive, and innovative in our approach to managing risk and staying safe. As always, we want to hear your feedback, so let us know what you think and what you would be interested in hearing about.

You can provide comments via your podcast download site or email us at FTSC at flighttestsafety.org. For this month's focus topic, I was fortunate enough to conduct a phone interview with Dr. Nancy Levison. She is a professor of aeronautics and astronautics and also a professor of engineering systems at the Massachusetts Institute of Technology.

Professor Levinson conducts research on the topics of system safety, software safety, software and system engineering, and human-computer interaction. The interview will be presented in two parts, this month and next month. In this first part, Dr. Levinson shares with us her thoughts on STAMP, Systems, Theoretic Accident Modeling and Processes, and what inspired her to develop that process. ♪

Thank you, Dr. Levison, for joining us today. I want to ask if you can briefly describe what inspired you to develop STAMP and STPA.

Actually, my degree was, I had a PhD in computer science, but when I first got my degree, which was 40 years ago, I got called by a huge ground system, it was called then, and they were building a torpedo for the Navy. And this was 1980, and they had...

And they were really concerned about it. They called it the problem software safety, and I said I've never heard of anything like that. And they said, well, if you could help us, we'd really appreciate it. So I said, well, I don't know anything about it, but I'll try.

And that's how I sort of got involved in this whole thing and realized, and I learned a lot about system safety here, and I realized that what we were doing didn't apply.

for software intensive systems like this one. Every single one of our safety and hazard analysis approaches and our risk assessment approaches were all developed in the 1960s or before, when all of our systems were composed of electromechanical components. And the problem in accidents was one of these components would fail.

But that's not... All of a sudden, in the 1980s and beyond that, we now are building systems where everything has catastrophe in it, where the complexity of the systems has increased exponentially, and the role of humans in the system is changing, and our causes of our accidents have changed. So I decided I had to figure out some way

Well, my first approach was to try and add software and human-certified human factors into the old techniques, and I realized that was never going to work.

The problem is that the assumption of the old technique is that accidents are caused by component failure. But that's not what's happening anymore. The cause of accidents has changed. So that's when I developed this new causality model, SAMS.

And the difference with SAMP is that instead of treating accidents as caused by failures, we treat it instead as not a failure problem but a control problem. We're not controlling adequately, controlling the behavior of the system. Now, that includes component failure because we have to control component failure, but it also includes other things like it.

unsafe interactions between components, unsafe human behavior, and other things so that it's a more general accident causality model. And so we're able to identify and prevent a much larger number of components.

The first time I tried this, when I first came up with this, it was so different. I was really concerned that everyone was going to think I'd lost my mind. So I did talk about it. But the first day, and we started trying it quietly on a few projects.

But then a friend of mine who knew what I was doing without telling me tried it on the new U.S., at that time, new U.S. missile defense system just before deployment and test in 2004. And it turned out the hazard was inadvertent launch. And it turned out that these two people in five months

who knew nothing about the system to begin with, found so many paths to inadvertent launch that launch deployment was delayed for six months and it cost several hundred million dollars to fix the things these two people found. So then I decided that this would work. Not only worked well, and it's been shown now every time we compare it, it works much better than the old technique.

But it also turns out to be cheaper. And it can be done earlier, as I think you've probably heard during the meeting, that you can use this to design safety into the system instead of trying to change things later.

Great. Thank you. So as you have worked with this over the years and today, as you look out across the industrial landscape, what industries do you see embracing this process and how is it able to give them a better and safer design or safety process overall?

First of all, it's used by hundreds and hundreds of companies now. This is one of the most widely used techniques that you may not have heard of. It is very widely used. It's perhaps most used in automobiles and autonomous automobiles because they have astounding amounts of software in them now. The auto you drive today has 100 million lines of software in it.

have maybe doubled that. It

We're talking about enormous amounts. You know, you think about the F-35, the latest, greatest military jet, and it probably has, I don't know, maybe 25 million lines of code in it. And think of your car with 100 million. So basically, virtually every automobile company is now using this, and most of the autonomous car companies. Not for Tesla for some reason.

seem to think they know what they're doing better. The second most widely used industry is aviation.

Embraer is using a lot of their systems. Defense aviation is using it. We're working with the Army now in the future vertical lift program to help them design safer vehicles for the future, both manned and unmanned.

And the other industries are probably less using it, less than those three, aviation, defense, and automotive. We'll pick up with part two of the interview with Dr. Levinson next month, where she will continue to share her insights into STAMP and STPA, as well as tell us how she deals with the human element in her process.

We're debuting a new feature this month called On the Web. This will highlight information you can access on the Flight Test Safety Committee webpage, www.flighttestsafety.org. This month, we are highlighting the recently updated Airshow Display Flight Guidance found in the Recommended Practices tab of the website. In 1987, SCTP formed an Airshow Safety Committee with members Joe Jordan, Bruce Peterson, Frank Sanders, and Roy Marten.

They were chartered to document lessons learned from SCTP members who were experienced air demonstration pilots. The result of that committee's work was a 1989 paper entitled Airshow Execution by Roy Martin and Frank Sanders. In 2019, the Flight Test Safety Committee began researching airshow flying recommended practices and references that could be shared on the Flight Test Safety Committee website recommended practices page. These resources are intended to aid planning, workups, and show execution considerations.

Elements of the original 1989 SETP paper have been incorporated with the contemporary airshow planning information to expand the concepts from that earlier paper. In this issue of the Flight Test Safety Fact, we'll find The European Aviation Safety Agency issues a Vertical Takeoff and Landing Means of Compliance proposal, sure to be a conversation starter.

The virtual Flight Test Safety Workshop Trip Report. Yes, we know it was a virtual event, but since we all know what a trip report is, Mr. Pete Donath shares his notes with us. And finally, in the Chairman's Corner, Tom Huff offers observations about flight test safety that are out of this world. If you do not currently receive the Flight Test Safety Fact, you can find it on our website, www.flighttestsafety.org. Just click on News at the top of the webpage. And here's what we know right now for upcoming events.

Reminder, as the guidelines for group events continue to change and evolve, please check directly with the sponsoring organizations for the most up-to-date information. The 2020 AIAA Aviation Forum program is going to be a 100% virtual event that will take place 15 through 19 June. Please check the AIAA website for the latest information and details.

Planning continues to move forward for the SATP Annual Symposium and Banquet in Anaheim, California, 23 through 26 September. The call for papers is out with a deadline of 15 June. And lastly, the European Flight Test Safety Workshop, scheduled for 13 to 16 October in London, England. The theme this year is Improving Flight Test Safety through Enhanced Safety Risk Management. The call for papers is out with a deadline for submission of 31 July.

And that'll wrap us up for this month. Please join us next month for part two of our interview with Dr. Levinson. We welcome your feedback as always and ask you to share this with your teams and friends you think are better. And until next time, be safe, be smart, be ready. So long, everyone.