Re: [SystemSafety] Sorry about message just sent -- substitute this one

From: Nancy Leveson < >
Date: Thu, 10 Oct 2013 21:39:15 -0400

Sorry, my mail system somehow sent my message while I was still typing it. Here is my complete message:

I don't know what prompted Peter's critique of STAMP. But I feel compelled to respond. [Peter's comments are in italics]

*Two hundred fifty years ago, David Hume proposed two characterisations of
> cause which have persisted ... Ten years ago, Nancy announced that she
> had a new conception of causality, which was embodied in STAMP. I saw, and
> continue to see, a problem in redefining a concept which has had a good and
> productive run in science for three centuries (if not two and a half
> millenia). It could well be that this new concept is a very useful concept;
> it could be very helpful in identifying areas of interest in accident
> investigation; indeed, judging by the interest in STAMP I imagine many
> people think it is. But why not choose a different word for it?*

Actually, I never claimed to have a new conception of causality. I had a new model of accident causality that is built upon the systems theory model of causality. I did not invent systems theory. I carefully spent a chapter in my book describing basic systems theory and how STAMP uses it.

The world has changed a lot in the past 250 years, particularly the world of engineering. Whole new fields have been created, some to explain the behavior of new machines. An example is the development of thermodynamics to explain the behavior of steam engines and their tendency to explode and cause accidents. After WWII, the growth of new technology exploded, with the notable introduction of the computer, which has revolutionized the world of engineering. New types of math and engineering concepts were invented (or resurrected, such as Boolean algebra) to keep up. To say that a philosophical concept was good enough 250 years ago so it should still be good enough today reminds me of Kelvin's [alleged] statement in 1900 that "There
is nothing new to be discovered in physics now; All that remains is more and more precise measurement."

As we build more complex systems, new engineering techniques (and sometimes new math) is needed to keep up. Accident causes are changing as the design of our systems changing, or causes are at least increasing as the design of our systems change. The argument in my new book is that what was adequate in the past is no longer adequate. STAMP is a new accident causality model that extends the older models to include new accident causes in our increasingly complex world (it still includes the old ones, i.e., the old models are a subset). In reality, STAMP is not really "new" in that it is simply an application of systems theory to the specific concept of safety, as I said above. Much of what is in STAMP is implied in the writings of the aeronautical engineers who invented System Safety in the late 1940s and 1950s (such as C.O. Miller who claimed to have come up with the term System Safety). Systems theory itself was a reaction to exactly the kind of philosophical thinking that Peter's alludes to because the traditional concepts did not fit the world of engineering that was beginning to appear in the 1940s and 1950s. Systems theory was a reaction to analytic reductionism (invented by Descartes and others) which assumes that a system is the sum of its parts. Systems theory, which underlies System Engineering (which arose at the same time in the 1950s) instead assumes that a system can be *more than* the sum of its parts. System Safety and System Engineering were closely allied in the 1950s missile defense systems for which they were originally developed. Analytic reduction was an important concept in the development of modern physics and is still very useful for a large number of systems, but after 200 years, engineers started to build systems for which something new was needed.

> *People who like STAMP could *obviously* use WBA for parts of what they
> do - the two methods are compatible. And they would see the same advantage
> as other WBA users. The only hindrance to such practice is use of the word
> "causal" for two different concepts.*
> I have no idea what Peter is saying here. STAMP is a model, it is not a
method. I assume he is referring to CAST. [I am the one that started this confusion my not coming up with the name CAST as the accident analysis method built on STAMP soon enough. Sorry, but it is in my book.] I don't know what it means that two methods are "compatible." What is needed is a scientific or empirical evaluation and comparison. If something can be done in CAST, why would people want to use WBA for parts of CAST? Sorry, but I am confused.

While there have been few careful evaluations of CAST, there have been lots of STPA (the hazard analysis method built on the STAMP philosophical foundation), many done by groups independent of mine, and I hear about them only after the fact. In the comparisons, STPA finds the same causal scenarios found by the traditional hazard analysis methods but also finds things not found by them (and which cannot be identified by them). In one recent evaluation by EPRI, experts in FTA, ETA, FMEA, HAZOP and some other things were independently given a nuclear power plant design to analyze. The EPRI folks heard about STPA and added it to their experiment. STPA came out the best. What was most interesting is that there had been a serious incident in the plant whose design was used in the analyses, although none of the analysts knew that. STPA was the only method that found that accident scenario. Everything is proprietary so I don't know the details, but one of my students who participated in the STPA analysis of the plant told me that the other methods not only did not find the accident scenario but they also could *not* have identified it. Again, this was a real incident.

> *
> The other thing about using STAMP is you have to buy the model. Now, I'm
> sure it is helpful, because the people developing STAMP are very smart and
> very dedicated and have been at it for a decade. But is the model right?
> One might well be able to persuade engineers that the STAMP
> social/organisational model is the bee's knees, but it is a quite different
> matter to persuade the experts in those things, the organisational
> scientists....*

I don't know what it means for a model to be "right." As Box said, "All models are wrong, some models are useful." The question is whether STAMP is more useful than alternative models, and the evidence so far is that it is

I write for engineers and apply to my methods to engineering systems primarily. So whether organizational scientists would like STAMP or not has not really come up although several people in the social sciences have started to look at STAMP. We and others have tried it on some social systems, and it has worked well. But I am not an organizational scientist so I will not make any claims about its applicability. We have, to date, concentrated on technical systems but we are now investigating how to apply STPA to organizational systems. Stay tuned.

> *
> Constance Perrin wrote a book in which she investigated some incidents at
> nuclear power stations and came to the conclusion that there was a tension
> between the way the plant was conceived to work organisationally and the
> architecture of plant operations impregnated in the minds of the operators,
> who came mostly from the "nuclear navy", which had/has a modus operandi
> completely different from the intended plant-operations architecture. A
> crucial insight. It is not obvious to me how a STAMP analysis would lead
> you to the same conclusion. *

Actually, this is a basic concept in STPA and one used in an STPA analysis. It has to do with inconsistent mental models.

> *Ten years ago, some colleagues in Braunschweig compared analyses of the
> same accident (the Brühl derailment) using WBA and using STAMP. STAMP
> identified a lot of organisational features of the Deutsch Bahn (German
> railways, as it then was; now it's DB). STAMP likes to see feedback, but the
> DB, like many German organisations, is hierarchical and STAMP wanted to see
> cycles where things were acyclic. It wouldn't have been helpful, because,
> well, I guess you could try to tell DB to change things, but they would say
> "we have been doing it like this for over a century; here are the reasons
> we do it this way (giving you the very thick history book); it has evolved
> so and it more or less works; and if we change it to something new we are
> likely to introduce weaknesses which we won't know about until we start
> having accidents because of them." And, you know, that's not a bad set of
> reasons: you don't change things that aren't really broken, even when a
> major scientist redefines "broken" for you. (In contrast, they are happily
> adopting WBA through third-party recommendation and training.)*
> This seems like a misunderstanding about STAMP. A basic concept in systems
theory and STAMP is the modeling of systems as hierarchies and, indeed, hierarchy theory. So it should work well in a hierarchical system. I don't know what Peter is referring here to as "cycles" and things being "acyclic". STAMP includes the concept of feedback control loops, but these are not "cycles." Perhaps the people who used CAST (which is what I assumed they did as STAMP is not a method) on the DB didn't understand CAST or STAMP? The railway industry is certainly one of the last to start using STPA. But there are a few people around the world who are using it, but apparently not in Germany. The transportation research group at the University of Braunschweig has started a new conference on STAMP/STPA, the first meeting was in May. But most of the transportation applications I heard about there were in other forms of transportation. As I have not personally tried it on railways I can't really comment much. I do have one student who is doing that now.


> --
> Prof. Nancy Leveson
> Aeronautics and Astronautics and Engineering Systems
> MIT, Room 33-334
> 77 Massachusetts Ave.
> Cambridge, MA 02142
> Telephone: 617-258-0505
> Email: leveson_at_xxxxxx > URL:

Prof. Nancy Leveson
Aeronautics and Astronautics and Engineering Systems
MIT, Room 33-334
77 Massachusetts Ave.
Cambridge, MA 02142

Telephone: 617-258-0505
Email: leveson_at_xxxxxx

_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Fri Oct 11 2013 - 03:39:27 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST