[SystemSafety] Critical Design Checklist

Andrew Rae andrew.rae at york.ac.uk
Tue Aug 27 12:06:53 CEST 2013


A few through-life safety items I'd expect to see in a design safety review
checklist:

1) What assumptions have you made about the design, including:
      - the way the design will be operated
      - the physical environment it will be operated in
      - other systems it will interact with
      - the performance of components and subsystems (including failure
modes and rates of failure)
      - the way the system will be maintained and inspected
      - the way the system will change over time

2) What systems are in place to support these assumptions (i.e. to
encourage them to come true)?

3) What systems are in place to create/collect, monitor and react to
evidence related to these assumptions?

4) What is the evidence that these systems are suitably trustworthy given
the reliance you place on each assumption?

5) Under what circumstances would the current claims of safety be
invalidated? What mechanisms are in place to look for those
circumstances, and (provisionally) what action will be taken when they
arise?

Note that the particular focus of these questions is the design safety
analysis - i.e. looking for evidence that the designers understand that
safety is not something that is demonstrated at a particular point in time,
but is something that must be continuously tested and questioned, and that
the design (including safety analysis) must support that continuous
management. It's hard to capture the "spirit" of the questions in the
questions themselves - that's one of my
concerns with a raw checklist. Each question really needs an explanation
for why it is being asked.

My system safety podcast: http://disastercast.co.uk
My phone number: +44 (0) 7783 446 814
University of York disclaimer:
http://www.york.ac.uk/docs/disclaimer/email.htm


On 27 August 2013 10:42, Peter Bishop <pgb at adelard.com> wrote:

> This may be wandering into the realms of system safety, but I would extend
> 1, 2 because we need to accommodate human fallibility and limitations in
> knowledge by having some kind of fallback or recovery strategy.
>
> A If there are residual doubts about requirements or implementation, are
> there any alternative systems that can maintain safety? (defence in depth
> principle)
> B What what features exist for identifying malfunctions in operation, and
> implementing design rectifications over the operating lifetime.
>
> Peter Bishop
> Adelard LLP
>
> Martyn Thomas wrote:
>
>>
>> On 26/08/2013 21:37, Driscoll, Kevin R wrote:
>>
>>>
>>> For NASA, we are creating a Critical Design Checklist:
>>>
>>> •       *Objective*
>>>
>>> -     *A checklist for designers to help them determine if a
>>> safety-critical design has met its safety requirements*
>>>
>>>
>>>  Kevin
>>
>> For this purpose, I interpret your phrase "safety requirements" for a
>> "safety-critical design" as meaning that any system that can be shown to
>> implement the design correctly will meet the safety requirements for such a
>> system in some required operating conditions.
>>
>> Here's my initial checklist:
>>
>> 1. Have you stated the "safety requirements" unambiguously and
>> completely? How do you know? Can you be certain? If not, what is your
>> confidence level and how as it derived?
>> 2. Have you specified unambiguously and completely the range of operating
>> conditions under which the safety requirements must be met? How do you
>> know? Can you be certain? If not, what is your confidence level and how as
>> it derived?
>> 3. Do you have scientifically sound evidence that the safety-critcal
>> design meets the safety requirements?
>> 4. Has this evidence been examined by an independent expert and certified
>> to be scientifically sound for this purpose?
>> 5. Can you name the both the individual who will be personally
>> accountable if the design later proves not to meet its safety requirements
>> and the organisation that will be liable for any damages?
>> 6. Has the individual signed to accept accountability? Has a Director of
>> the organisation signed to accept liability?
>>
>> Of course, there is a lot of detail conceled within these top-level
>> questions. For example, the specification of operating conditions is likely
>> to contain detail of required training for operators, which will also need
>> to be shown to be adequate.
>>
>> But there's probably no need to go into more detail as you will probably
>> get at least one answer "no" to the top six questions.
>>
>> What will you do then?
>>
>> Regards
>>
>> Martyn
>>
>>
>>
>> ------------------------------**------------------------------**
>> ------------
>>
>> ______________________________**_________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-**Bielefeld.DE<systemsafety at TechFak.Uni-Bielefeld.DE>
>>
>
> --
>
> Peter Bishop
> Chief Scientist
> Adelard LLP
> Exmouth House, 3-11 Pine Street, London,EC1R 0JH
> http://www.adelard.com
> Recep:  +44-(0)20-7832 5850
> Direct: +44-(0)20-7832 5855
> ______________________________**_________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-**Bielefeld.DE<systemsafety at TechFak.Uni-Bielefeld.DE>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130827/597d8524/attachment.html>


More information about the systemsafety mailing list