[SystemSafety] Request for references on measures to manage failures for homogeneous sensor redundancy

paul_e.bennett at topmail.co.uk paul_e.bennett at topmail.co.uk
Fri Dec 13 22:21:18 CET 2019


On 12/13/2019 at 7:15 AM, "Watts Malcolm (AE-BE/ENG1-AU)" <Malcolm.Watts at au.bosch.com> wrote:
>
>Colleagues;
>
>Can I ask for your assistance please ?  I'm looking for references 
>that show approaches to using multiple redundant (possibly 
>unreliable) sensors in safety-related systems.
>
>I am supporting a project team working on a safety-related 
>embedded system (with safety requirements equivalent to automotive 
>ASIL B) that must make safety-related decisions on the basis of 
>input from an array of  sensors, all of the same type, in 
>proximity.  (The sensors are in slightly different locations in 
>the same physical environment, so their expected output will be 
>highly correlated but not identical).
>There may be from 3 to 8 sensors; this number relates to the 
>application and is not driven by safety concerns.
>
>Currently, the sensors are developed according to a safety 
>standard, and are allocated safety requirements.
>The team wants to understand the impact of changing to a different 
>sensor, that may not have been developed in accordance with safety 
>requirements.  I expect requirement decomposition won't be 
>possible.
>
>What approaches may be viable for achieving and demonstrating a 
>safe system, if it must use data from unreliable sensors, with 
>significant (homogeneous) redundancy ?
>
>On one hand, we want to take advantage of the redundancy... on the 
>other, convincingly demonstrating freedom from dependent failures 
>in an array of identical sensors seems problematic.
>
>What are our options for safety mechanisms that take advantage of 
>the redundancy we can achieve ?
>
>I'm aware of work on sensor fusion, on sensor failure detection 
>and classification, on redundant sensors in autonomous vehicle 
>development and on "reliable consensus decisions" for (e.g.) 
>navigation systems and distributed time signals.
>
>What I've not found so far is approaches to formal compliance with 
>a safety standard, without using "reliable" (in the sense of 
>having some demonstrable safety property) sensors, but instead 
>using sensors that are not developed to a safety standard.  I'm 
>struggling to find anything that takes advantage of the degree of 
>redundancy available, to provide evidence of 
>reliability/correctness.  I'm increasingly seeing (non-safety) IoT 
>systems with many sensors, so I expect this question will shortly 
>come up in many other safety-related applications.
>
>I can think of approaches (BBNs, Kalman filtering...) that I feel 
>should be able to provide evidence of the confidence achieved (at 
>system design time) in a safety mechanism applied at runtime, but 
>I haven't found good references around how these might be applied 
>specifically to safety systems.  This feels something like a 
>"checker" safety pattern, but where the check is on some 
>collective property of the sensor network.  I'd like to turn 
>"feeling" into convincing evidence :).


One thing to stir into your consideration will be ensuring that you have
sufficient separate channels to pass sensor data through. You cannot
consider  pulling all sensor data into one processor to determine what
is happening. You had better ensure that you have several channels of
information flow that cross checking and voting can be considered.

Whilst the sensors may share the same relative environment, you have
correctly identified that you may not get the same reading from them all.

Are there any physical or performance characteristics for teh sensors
that may give you a clue to the sensor integrity individually. Like those
that produce 4-20mA signals, you have an idea when the sensor is not
performing as expected and you can begin to make allowances, but still
extract useful and accurate data. Understanding the off-spec and failure
cases for each of your sensor types may be crucial to developing the
right interfacing.

Not sure I can recall which tome to suggest that covers these notions
though.


Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************



More information about the systemsafety mailing list