New Accident Model for Engineering Safer Systems (Leveson, http://sunnyday.mit.edu/16.355/)
Symptom – “something that indicates the existence of something else”, Webster dictionary http://www.merriam-webster.com/dictionary/Symptom
It is my understanding that STAMP focuses on “constraints necessary to limit system behavior to safe changes and adaptations” (p.12). The model briefly touches upon a symptom as “the process leading to an accident (loss event)... described in terms of an adaptive feedback function that fails to maintain safety as performance changes over time to meet a complex set of goals and values” (p.26).
Reading this article I kept asking myself if complex systems are just “complex and often imperfect human artifact”, could one characterize symptoms of upcoming accidents? In other words, if we can classify accident factors (p.21), can we characterize accident symptoms?
The article briefly mentions that “proximity” to systems has changed over time (p. 14). In the past, operators had direct access to their systems and were able to get “direct physical feedback” from the system. More experienced operators could have indentified changes in the system’s behavior or “feel” erroneous symptoms (or what is called “detect maladaptive changes” p.26). Such ability usually came from “gut feeling” or intuition, which in reality was based on previous experience and undocumented assumptions.
Modern complex systems do not give us luxury of “feeling” the system. Moreover, post-mortem accident investigation may not reveal the symptoms that operators failed to recognize before that accident. Available factual data may not necessarily lead us to the correct interpretation of that data (p.26). But we may assume that such symptoms are usually non-linear, dynamics (with feedback loops) and adaptive to the environment.
It might sound as gross generalization, but I argue that STAMP should not only help to control the “beast”, but also explain “why and when the beast wants to get out from the cage”. I will take a risk of classifying such symptoms into three categories:
(1) external symptoms: symptoms that emerge as the result of external socio-technical environment (including change and adaptation of new safety constrains) that forces the system to adapt and lead to maladaptive changes. This can be categorized as expected and inevitable results if and when erroneous processes influence the system and its environment.
(2) interface symptoms: symptoms that emerge as the result of interaction between the system and its operator, the system and other systems. This is the closest we can get to the old way “feeling the vibration” the system and being able to get feedback from it.
(3) internal behavioral symptoms: unintended or unforeseen symptoms that can be best identified by the designer or peer-reviewers of the system. My intuition, tells me that this is the most difficult symptom to indentify and categorize (and decompose), which can be done only through extensive testing of the system.
No comments:
Post a Comment