[SystemSafety] Does "reliable" mean "safe" and or "secure" or neither?

[paul_e.bennett at topmail.co.uk]

On 24/04/2016 at 7:12 PM, "Roberto Bagnara" <bagnara at cs.unipr.it> wrote:

[%X]

>OK.  In my example a "trial" would consist in exercising the  
>overall system
>under in-spec conditions.  The "experiment" would consist in 
>recording the
>in-spec and out-of-spec behaviors of the various system components.
>We would say that two outcomes are "the same result" if they are 
>either both
>in-spec or both out-of-spec.  We perform many "repeated trials" 
>and we thus
>determine the "reliability" of each component in the context of 
>the overall
>system.
>
>Do you think there is something flawed in the above?  That is, do 
>you
>think that the use of the word "reliability" in that context makes 
>sense?
>If it does not make sense, can you please indicate where the flaw 
>is?
>Kind regards,
>
>   Roberto

For high integrity systems I would say your above testing regime
does not go far enough. We need to assess system behaviour when
the inputs are not all within specification. I would hope that software
designed well enough would always deliver sensible output given 
inputs within its limitations.

To prove integrity, I think, requires applying some stress to the system
above and beyond the normal specification with the expectation that
the system would still behave in a rational manner. This may mean
keeping the system output within limits despite out of limits system 
inputs. It may mean detecting the out of limits inputs and ensuring a
tidy shut-down to a safe state (such behavioural expectations should 
also be a part of the specifications).

Much like mechanical engineers test the integrity of a mechanical 
component there are three stages to the inspection and testing.

Stage 1 is a thorough (often visual) examination of the component
against the design information. This inspection confirms that the 
component appears to meet the design intent and quality constraints.

Stage 2 is a functional test. This is the within limits test that the actual 
functionality and performance is met and agrees with the design intent.

Stage 3 (usually on a sample of mechanical components) is the stress
testing of components where input limits are exceeded and behaviour
under duress is observed. Failure of the component should not be too
close to the published limitations of the component.

We have carried that regime into electrical and electronics (see any
component data-sheet) and we should really be carrying this idea into 
the software component also (note that I already do so).

Regards

Paul E. Bennett IEng MIET
Systems Engineer

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************