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

[Nancy Leveson]

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.

Nancy

>
>
>
>
> --
> 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 mit.edu
> URL: http://sunnyday.mit.edu
>



-- 
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 mit.edu
URL: http://sunnyday.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20131010/cccee575/attachment.html>