ALARP for Engineers

Hi all,

the IMechE have published (in 2024) a document titled 'ALARP for Engineers: A Technical Safety Guide".

It's a really useful document that I am finding helpful in our support to our customer. Does anyone know if there is any other equivalent documents produced by any other Institutes (IET would be great) that will help in application of Safety Techniques for complex systems that include Software and Humans in the loop?

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. Applying a top level Safety Target to a lower level system is driving me mad and STPA changes the approach of quantification of hazards to be far more sensible and manageable from a System level point of view. 

Many Thanks,

SJ

Parents
  • Applying a top level Safety Target to a lower level system is driving me mad

    As a systems engineer, I also see this problem in requirements flow-down where, at some point, the requirement becomes 'black box', and isn't easily decomposable to a white box sub-requirement. EMC requirements are often like that. They try and add some coordinating roles but still haven't thought through what to actually test at the lower levels - e.g. PCB level - I did try some work on that but no one bought into it, I expect the same will happen in the general case.

  • EMC requirements are often like that.

    Er....yes. The problem is that nobody knows! Because the answer is that the whole system must work together, but until each part of the system is engineered you don't know how much of an EMC risk it is (in either direction). I spent years working on EMC for safety critical systems, and we quickly worked out that compliance to any standard was of no help at all in the safety case - having sat on the EN committee that drafted the standards for my industry I was well aware how much "best guessing" went into the figures, which meant that compliance to the standard gave no guarantee that the real world wouldn't be harsher than that! Inevitable, as if we'd written the standard for worst case the industry would have ended up massively over engineering. So for EMC for safety critical systems we just have to ensure that any EMC event (in or out of spec) causes the system to fail safe. But I'm lucky, I work in the rail industry where it's (relatively) safe to just stop the trains. I'm very glad I don't have to deal with EMC events in aerospace... 

Reply
  • EMC requirements are often like that.

    Er....yes. The problem is that nobody knows! Because the answer is that the whole system must work together, but until each part of the system is engineered you don't know how much of an EMC risk it is (in either direction). I spent years working on EMC for safety critical systems, and we quickly worked out that compliance to any standard was of no help at all in the safety case - having sat on the EN committee that drafted the standards for my industry I was well aware how much "best guessing" went into the figures, which meant that compliance to the standard gave no guarantee that the real world wouldn't be harsher than that! Inevitable, as if we'd written the standard for worst case the industry would have ended up massively over engineering. So for EMC for safety critical systems we just have to ensure that any EMC event (in or out of spec) causes the system to fail safe. But I'm lucky, I work in the rail industry where it's (relatively) safe to just stop the trains. I'm very glad I don't have to deal with EMC events in aerospace... 

Children
No Data