embedded programming for unreliable hardware

embedded programming for unreliable hardware

[tmoran]

Can someone recommend a book or something on techniques for embedded
control when the sensors and activators are not terribly reliable?
I've been playing with X10 home stuff and it seems about 95% reliable.

Re: embedded programming for unreliable hardware

[Jeffrey R. Carter]

tmoran@acm.org wrote:

> Can someone recommend a book or something on techniques for embedded
> control when the sensors and activators are not terribly reliable?
> I've been playing with X10 home stuff and it seems about 95% reliable.

I can't refer you to any references, but this specific case seems pretty clear. 
I presume that with X10 an occasional error is acceptable. If it's > 90% 
reliable, then reading a sensor 3 times should give at least 2 that agree; that 
would be the correct value. 2 out of 3 won't agree 0.25% (at 95%) of the time, 
assuming errors are independent; you can probably see how to deal with that rare 
case if you can't ignore it.

Things get a little more interesting with binary sensors. 2 out of 3 will always 
agree, and those 2 will be wrong 0.25% of the time.

For actuators, it depends on whether you command to an absolute value or not. If 
you command to an absolute value ("turn on") then issuing the command twice 
should ensure that it's performed. If you command a relative change ("toggle 
power") then you'd need to issue the command, check the result through a sensor, 
and reissue if it didn't take. Issuing twice will work 99.75% of the time.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

Re: embedded programming for unreliable hardware

[Dmitry A. Kazakov]

On Wed, 15 Feb 2006 05:54:27 GMT, Jeffrey R. Carter wrote:

> For actuators, it depends on whether you command to an absolute value or not. If 
> you command to an absolute value ("turn on") then issuing the command twice 
> should ensure that it's performed. If you command a relative change ("toggle 
> power") then you'd need to issue the command, check the result through a sensor, 
> and reissue if it didn't take. Issuing twice will work 99.75% of the time.

Somewhat complementary technique is safe actuators design. Some actuators
have a safe-state command, they perform it automatically if no new command
comes. For example, a lift truck holds on the load by default. If you want
to lift it up, you have to permanently repeat "up", "up", "up"... Should
one command not arrive, no problem.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de