Re: [SystemSafety] the bomb again

From: Peter Bernard Ladkin < >
Date: Fri, 11 Oct 2013 09:47:30 +0200


On 11 Oct 2013, at 03:39, Nancy Leveson <leveson.nancy8_at_xxxxxx

> 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



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Fri Oct 11 2013 - 09:47:42 CEST

This archive was generated by hypermail 2.3.0 : Sat Feb 23 2019 - 10:17:06 CET