[SystemSafety] the bomb again

[Nancy Leveson]

Peter,

I wrote my message to try to point out some things about which I thought
you were mistaken about STAMP. My very least favorite thing to do is to
argue about deep concepts on a superficial medium like an email list. So I
have no desire to continue this discussion by answering your questions. I
am busy incredibly busy applying STAMP-based tools right now on an aircraft
system, air traffic control, a surgical robot, and supervising students who
are working on additional systems including radiation therapy, UAVs, human
factors, automobiles, high speed rail, nuclear power, and hospital safety.
That is a more important use of my time than arguing on this list. What I
said I stand by, whether you understand it or not.

Nancy


On Fri, Oct 11, 2013 at 3:47 AM, Peter Bernard Ladkin <
ladkin at rvs.uni-bielefeld.de> wrote:

> On 11 Oct 2013, at 03:39, Nancy Leveson <leveson.nancy8 at gmail.com> wrote:
>
> I don't know what prompted Peter's critique of STAMP.
>
>
> Matthew was talking about certain organisational-behavioral aspects of
> systems, and suggested that the STAMP "methodology" could assist me in
> analysing those (message of 8 October , 07:43). So I started to say where I
> thought not (message of 9 October, 13:52). Hence the list of examples in
> which organisational behaviorists had a lot to say.
>
> I feel that the insights of organisational theorists have been given short
> shrift in recent discussion and I wanted to restore what I take to be the
> balance. My view is that STAMP, or CAST, does not do all that they can do
> for sociotechnical systems. (Indeed, if you recall the discussion from 2010
> between Daniel Jackson and ourselves, you'll recall that Daniel and I think
> that STAMP, this time STPA, doesn't do some necessary things which an Alloy
> analysis, respectively an OHA, can.)
>
> It seems there are people who think general systems theory, in whatever
> form, can do more in the way of specific system analysis than I think it
> currently can (Matthew?). So it's worth discussing specifics and I had
> hoped that my specific examples could be discussed (the Brühl study, my
> TCAS and RCM papers, Perrin's work).
>
> To your general point about systems theory - yes, it is obviously a good
> and helpful thing, and we use it too. STAMP is not the only embodiment of
> it.
>
>
>> *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.
>
>
> Yes, I was referring to what you now call CAST.
>
> ...  I don't know what it means that two methods are "compatible."
>
>
> !!!!!
>
> I don't know what it means for a model to be "right." As Box said, "All
>> models are wrong, some models are useful."
>>
>
> That the model is an accurate description of the world; specifically, an
> abstraction. (See my ancient paper on models and abstractions for a precise
> explanation.)
>
> I am big on abstractions, because I work with specifications and
> specifications are abstractions - at least, the intent is that they are.
> Abstractions are assertions that are true.
>
> Some people use the word "model" to cover abstractions also, for example
> specifying something in TLA or in I/O Automata. I prefer to keep the
> narrower meaning. If you use the wider meaning, then Box's statement above
> is flat wrong. If you use the narrower meaning, it is insightful.
>
> *
>> Constance Perrin wrote a book in which she investigated some incidents
>> ..... 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.
>
>
> Such a phenomenon is a basic concept in RCM too; the question for me is
> not whether it occurs in the ontology of a particular
> method/model/methodology/technique, which can be achieved by fiat. The
> question here is whether you can derive Perrin's conclusion from a CAST
> analysis of Perrin's examples. And the further question (as with the Snook
> example) is whether one could have derived that conclusion without having
> had Perrin's prior analysis to point the way.
>
> *Ten years ago, some colleagues in Braunschweig compared analyses of the
>> same accident (the Brühl derailment) using WBA and using STAMP.......*
>>
>
>
>>
>> This seems like a misunderstanding about STAMP.
>
>
> Are you familiar with the study? It is not the first time that it has been
> mentioned here. Could you comment on it? As I remember it, Jens told me you
> helped by answering lots of questions during the analysis.
>
>  I don't know what Peter is referring here to as "cycles" and things being
> "acyclic".
>
>
> Standard terminology for graphs.
>
> STAMP includes the concept of feedback control loops, but these are not
> "cycles."
>
>
> If you are writing things like functional block diagrams, a standard
> technique for visualising control loops (IEC 61131), then a loop is most
> obviously a graph-theoretic cycle.
>
>  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.
>
>
> There are two such groups researching transportation safety in Brunswick.
> The one to which you refer is the Institute for Transportation Safety and
> Automation (IVA), led by Eckhardt Schnieder. Then there is the Institute
> for Railway Engineering and Transportation Safety (IfEV), which
> traditionally works closely with Siemens Rail Automation division (Siemens
> colleague Jens Braband, for example, is also a Professor at IfEV). IVA,
> IfEV and my group put on the workshop where the Brühl study was presented
> in English.
>
> PBL
>
> Prof. Peter Bernard Ladkin, University of Bielefeld and Causalis Limited
>



-- 
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/20131011/5eec4402/attachment.html>