<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>You might may be something useful in <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Isermann, R. “Fault-Diagnosis Systems: An Introduction from Fault Detection to Fault tolerance”, Springer <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>However from your email you may have already looked at some of the options. In general though more advanced methods require you to have a good understanding (model) of how sensors will fail and how that can be observed. This implies you want a sensor with good data associated with it, ASIL rated or not. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Cheers.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> systemsafety [mailto:systemsafety-bounces@lists.techfak.uni-bielefeld.de] <b>On Behalf Of </b>Watts Malcolm (AE-BE/ENG1-AU)<br><b>Sent:</b> 13 December 2019 07:15<br><b>To:</b> systemsafety@TechFak.Uni-Bielefeld.DE<br><b>Subject:</b> [SystemSafety] Request for references on measures to manage failures for homogeneous sensor redundancy<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-AU>Colleagues;<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>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). <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU>There may be from 3 to 8 sensors; this number relates to the application and is not driven by safety concerns.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>Currently, the sensors are developed according to a safety standard, and are allocated safety requirements. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU>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. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>What approaches may be viable for achieving and demonstrating a safe system, if it must use data from unreliable sensors, with significant (homogeneous) redundancy ? <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>What are our options for safety mechanisms that take advantage of the redundancy we can achieve ?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>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 </span><span lang=EN-AU style='font-family:Wingdings'>J</span><span lang=EN-AU>.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>Can anyone point to any good references or advice that will help ? <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU>Mal.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-AU><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-AU style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>Best regards, <br><br><b>Malcolm Watts<br></b></span><span lang=EN-AU>Mal@ieee.org<o:p></o:p></span></p></div></body></html>