ALARP for Engineers

Steven Jones920 said:

I am also starting to look into STPA (I'm a Tim Kelly disciple, so working on Nancy Leveson processes feels disloyal, lol). I have the STPA handbook (all 188 pages of it). Can anyone recommend any additional resources that would help develop capability in this area please? it seems that a step change in how we perceive Hazards and Risk is both required and inevitable.

Ok, so I've had a merry evening reading the STPA handbook... 

STPA Handbook (MIT-STAMP-001)

Most of this approach seems to closely follow the standard V cycle approach for hazard and risk analysis (as is actually shown in the handbook), The new feature it introduces appears to be the "model the control structure" stage to support identification of the hazards. Which is a really good idea, and I can see why it's been developed for (or appears to have been developed for) the aerospace examples given. It would work excellently for those. However, it does feel to me that this modelling stage (as it's described here) would be disproportionately expensive and complex for many safety systems? Remembering that the process of developing this model itself is subject to the same potential specification and implementation errors as those it is trying to determine in the development of the system (just as developing an FTA or FMEA is), to do it well enough is not cheap. But for systems as critical as is described here worth it.

Aside from that, yes this handbook is very good guidance to good engineering safety management practice. It's not radical, but it is pretty much best practice. I'd say "pretty much" because what it doesn't appear to thoroughly address (or at least I couldn't find it except a brief mention at the start of chapter 3) is applying this to agile development environments. The authors could well say that's out of scope of this, but it is really important to consider when proposing safety management methodologies - they need to consider how the methodology itself has a built in allowance for constant changes to the the project implementation, and indeed scope. 

Interesting,

Thanks,

Andy

Steven Jones920 said:

I am also starting to look into STPA (I'm a Tim Kelly disciple, so working on Nancy Leveson processes feels disloyal, lol). I have the STPA handbook (all 188 pages of it). Can anyone recommend any additional resources that would help develop capability in this area please? it seems that a step change in how we perceive Hazards and Risk is both required and inevitable.

Ok, so I've had a merry evening reading the STPA handbook... 

STPA Handbook (MIT-STAMP-001)

Most of this approach seems to closely follow the standard V cycle approach for hazard and risk analysis (as is actually shown in the handbook), The new feature it introduces appears to be the "model the control structure" stage to support identification of the hazards. Which is a really good idea, and I can see why it's been developed for (or appears to have been developed for) the aerospace examples given. It would work excellently for those. However, it does feel to me that this modelling stage (as it's described here) would be disproportionately expensive and complex for many safety systems? Remembering that the process of developing this model itself is subject to the same potential specification and implementation errors as those it is trying to determine in the development of the system (just as developing an FTA or FMEA is), to do it well enough is not cheap. But for systems as critical as is described here worth it.

Aside from that, yes this handbook is very good guidance to good engineering safety management practice. It's not radical, but it is pretty much best practice. I'd say "pretty much" because what it doesn't appear to thoroughly address (or at least I couldn't find it except a brief mention at the start of chapter 3) is applying this to agile development environments. The authors could well say that's out of scope of this, but it is really important to consider when proposing safety management methodologies - they need to consider how the methodology itself has a built in allowance for constant changes to the the project implementation, and indeed scope. 

Interesting,

Thanks,

Andy