<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Are you, or someone you know, using voting within your embedded system designs?</title>
	<atom:link href="http://www.embeddedinsights.com/channels/2010/11/03/are-you-or-someone-you-know-using-voting-within-your-embedded-system-designs/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.embeddedinsights.com/channels/2010/11/03/are-you-or-someone-you-know-using-voting-within-your-embedded-system-designs/</link>
	<description>Shedding Light on the Hidden World of Embedded Systems</description>
	<lastBuildDate>Mon, 28 Jul 2014 16:18:37 -0400</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Lance ==)-----------</title>
		<link>http://www.embeddedinsights.com/channels/2010/11/03/are-you-or-someone-you-know-using-voting-within-your-embedded-system-designs/#comment-4271</link>
		<dc:creator>Lance ==)-----------</dc:creator>
		<pubDate>Fri, 05 Nov 2010 04:27:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=370#comment-4271</guid>
		<description>I&#039;ve been working with avionics control systems (DO-178B, level A) for almost 20 years and have seen a multiple voting schemes.  These systems are the ultimate in paranoia, as they start out with the assumption that not only might the sensors have errors, they&#039;re quite possibly lying (i.e., wrong with very reasonable values).

Because they&#039;re going on large commercial aircraft, these are scrutinized very closely by the FAA.  This has both advantages and disadvantages:  on the plus side, we&#039;re using the very best practices we *know* work; on the negative side, we&#039;re extremely slow to adopt practices that have yet to be compelling to the most skeptical safety engineers.  From an economic stand point, it is much easier and faster to defend a scheme by demonstrating similarity to an already approved one than show that a new one is in all ways superior.

With triply-identical sensors, after verifying that the sensors think they&#039;re healthy, the values are reasonable (both on their own and relative to earlier data from the same sensor), and filtering, then we compare the readings from the three and choose the middle one.  This minimizes the magnitude of any erroneous data.

With doubly-identical sensors for which there exists some combination of other sensor readings from which we can infer what this sensor ought to be reading, we choose the sensor that is closest to the synthesized reading, provided it is sufficiently close to the synthesized reading.

The question has always been:  with only two sensors (one of the three has declared itself bad or the synthetic reading is unavailable) that disagree, what do you do in circumstances where there is no fail-safe value?

Lance  ==)--------------------</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been working with avionics control systems (DO-178B, level A) for almost 20 years and have seen a multiple voting schemes.  These systems are the ultimate in paranoia, as they start out with the assumption that not only might the sensors have errors, they&#8217;re quite possibly lying (i.e., wrong with very reasonable values).</p>
<p>Because they&#8217;re going on large commercial aircraft, these are scrutinized very closely by the FAA.  This has both advantages and disadvantages:  on the plus side, we&#8217;re using the very best practices we *know* work; on the negative side, we&#8217;re extremely slow to adopt practices that have yet to be compelling to the most skeptical safety engineers.  From an economic stand point, it is much easier and faster to defend a scheme by demonstrating similarity to an already approved one than show that a new one is in all ways superior.</p>
<p>With triply-identical sensors, after verifying that the sensors think they&#8217;re healthy, the values are reasonable (both on their own and relative to earlier data from the same sensor), and filtering, then we compare the readings from the three and choose the middle one.  This minimizes the magnitude of any erroneous data.</p>
<p>With doubly-identical sensors for which there exists some combination of other sensor readings from which we can infer what this sensor ought to be reading, we choose the sensor that is closest to the synthesized reading, provided it is sufficiently close to the synthesized reading.</p>
<p>The question has always been:  with only two sensors (one of the three has declared itself bad or the synthetic reading is unavailable) that disagree, what do you do in circumstances where there is no fail-safe value?</p>
<p>Lance  ==)&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8211;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rick Matz</title>
		<link>http://www.embeddedinsights.com/channels/2010/11/03/are-you-or-someone-you-know-using-voting-within-your-embedded-system-designs/#comment-4269</link>
		<dc:creator>Rick Matz</dc:creator>
		<pubDate>Thu, 04 Nov 2010 09:33:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=370#comment-4269</guid>
		<description>I recently worked on a Steering Column Lock Module for a large automaker. Because of the threat that the steering column could lock while the car was in motion, it was rated  SIL 3 (Safety Integrity Level 3) application.

The way we implemented voting was this: There was a hardware path and a software path, each giving an output. These two outputs were ANDed together, and when the result was true, the system could lock.

Each of these paths used three separate inputs, and each of these inputs were tested against other system parameters to insure that they were true.

For example, the car had to be in PARK  and the engine was off to lock the steering column. The hardware path looked at the Park switch and the state of the key cylinder, while the software looked at the Park status message on the CAN bus.It also looked to see the ignition status, the engine status (OFF) and vehicle speed (0).

Even if the software was completely wrong, the hardware path would prevent the Steering Column Lock Module from locking the steering column while the car was in motion.</description>
		<content:encoded><![CDATA[<p>I recently worked on a Steering Column Lock Module for a large automaker. Because of the threat that the steering column could lock while the car was in motion, it was rated  SIL 3 (Safety Integrity Level 3) application.</p>
<p>The way we implemented voting was this: There was a hardware path and a software path, each giving an output. These two outputs were ANDed together, and when the result was true, the system could lock.</p>
<p>Each of these paths used three separate inputs, and each of these inputs were tested against other system parameters to insure that they were true.</p>
<p>For example, the car had to be in PARK  and the engine was off to lock the steering column. The hardware path looked at the Park switch and the state of the key cylinder, while the software looked at the Park status message on the CAN bus.It also looked to see the ignition status, the engine status (OFF) and vehicle speed (0).</p>
<p>Even if the software was completely wrong, the hardware path would prevent the Steering Column Lock Module from locking the steering column while the car was in motion.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
