Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Re:Predictive failures
Date: Tue, 16 Apr 2024 09:53:42 -0700
Organization: A noiseless patient Spider
Lines: 135
Message-ID: <uvmaet$1231i$2@dont-email.me>
References: <uvjn74$d54b$1@dont-email.me> <uvjobr$dfi2$1@dont-email.me>
 <uvkn71$ngqi$2@dont-email.me>
 <uvkrig$30nb$1@nnrp.usenet.blueworldhosting.com>
 <uvl2gr$phap$2@dont-email.me> <uvm7f5$pvu$1@nnrp.usenet.blueworldhosting.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 16 Apr 2024 18:53:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8f873457a009428ae193cacdeebfb978";
	logging-data="1117234"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+iSZGAKRAV1W6ohCc26Uyj"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:tbxpcyEezjvXUZ7QC7yR5ZfCFBs=
In-Reply-To: <uvm7f5$pvu$1@nnrp.usenet.blueworldhosting.com>
Content-Language: en-US
Bytes: 7805

On 4/16/2024 9:02 AM, Edward Rawde wrote:
>> Again, the goal is to be an EARLY warning, not an "Oh, Shit!  Kill the
>> power!!"
>>
>> As such, software is invaluable as designing PREDICTIVE hardware is
>> harder than designing predictive software (algorithms).
> 
> Two comparators can make a window detector which will tell you whether some
> parameter is in a specified range.

Yes, but you are limited in the relationships that you can encode
in hardware -- because they are "hard-wired".

> And it doesn't need monthly updates because software is never finished.

Software is finished when the design is finalized.  When management
fails to discipline itself to stop the list of "Sales would like..."
requests, then it's hard for software to even CLAIM to be finished.

[How many hardware products see the addition of features and new
functionality at the rate EXPECTED of software?  Why can't I drive
my car from the back seat?  It's still a "car", right?  It's not like
I'm asking for it to suddenly FLY!  Why can't this wall wart deliver
400A at 32VDC?  It's still a power supply, right?  It's not like I'm
asking for it to become an ARB!]

>> You don't want to tell the user "The battery in your smoke detector
>> is NOW dead (leaving you vulnerable)" but, rather, "The battery in
>> your smoke detector WILL cease to be able to provide the power necessary
>> for the smoke detector to provide the level of protection that you
>> desire."
>>
>> And, the WAY that you inform the user has to be "productive/useful".
>> A smoke detector beeping every minute is likely to find itself unplugged,
>> leading to exactly the situation that the alert was trying to avoid!
> 
> Reminds me of a tenant who just removed the battery to stop the annoying
> beeping.

"Dinner will be served at the sound of the beep".

[I had a friend who would routinely trip her smoke detector while cooking.
Then, wave a dishtowel in front of it (she was short) to try to "clear" it.]

Most places have specific rules regarding the placement of smoke detectors
to 1) ensure safety and 2) avoid nuisance alarms.  (I was amused to disover
that our local fire department couldn't cite the local requirements when
I went asking!)

Add CO and heat detectors to the mix and they get *really* confused!

> Better to inform the individual who can get the replacement done when the
> tenant isn't even home.

So, a WiFi/BT link to <whatever>?  Now the simple smoke detector starts
suffering from feeping creaturism.  "Download the app..."

Remind the occupants once a week (requiring acknowledgement) starting
a month prior to ANTICIPATED battery depletion.  When the battery is on
it's last leg, you can be a nuisance.

Folks will learn to remember at the first (or second or third) reminder
in order to avoid the annoying nuisance behavior that is typical of
most detectors.  (there is not a lot of $aving$ to replacing the
battery at the second warning instead of at the "last minute")

[We unconditionally replace all of ours each New Years.  Modern units
now come with sealed "10 year" batteries -- 10 years being the expected
lifespan of the detector itself!]

>> I'm not looking for speculation.  I'm looking for folks who have DONE
>> such things (designing to speculation is more expensive than just letting
>> the devices fail when they need to fail!)
> 
> Well I don't recall putting anything much into a design which could predict
> remaining life.

Most people don't.  Most people don't design for high availability
*or* "costly" systems.  When I was designing for pharma, my philosophy was
to make it easy/quick to replace the entire control system.  Let someone
troubleshoot it on a bench instead of on the factory floor (which is
semi-sterile).

When you have hundreds/thousands of devices in a single installation,
then you REALLY don't want to have to be playing wack-a-mole with whichever
devices have crapped out, TODAY.  If these *10* are likely to fail in
the next month, then replace all ten of them NOW, when you can fit
that maintenance activity into the production schedule instead of
HAVING to replace them when they DISRUPT the production schedule.

> The only exceptions, also drawing from other replies in this thread, might
> be be temperature sensing,
> voltage sensing, current sensing, air flow sensing, noise sensing, iron in
> oil sensing,
> and any other kind of sensing which might provide information on parameters
> outside or getting close to outside expected range.

> Give that to some software which also knows how long the equipment has been
> in use, how often
> it has been used, what the temperature and humidity was, how long it's been
> since the oil was changed,
> and you might be able to give the operator useful information about when to
> schedule specific maintenance.

I have all of those things -- with the exception of knowing which sensory data
is most pertinent to failure prediction.  I can watch to see when one device
fails and use it to anticipate the next failure.  After many years (of 24/7
operation) and many sites, I can learn from actual experience.

Just like I can learn that you want your coffee pot started 15 minutes after
you arise -- regardless of time of day.  Or, that bar stock will be routed
directly to the Gridley's.  Because that's what I've *observed* you doing!

> But don't give the software too much control. I don't want to be told that I
> can't use the equipment because an oil change was required 5 minutes ago and
> it hasn't been done yet.

Advisories are just that; advisories.  They are there to help the user
avoid the "rudeness" of a piece of equipment "suddenly" (as far as the
user is concerned) failing.  They add value by increasing availability.

If you choose to ignore the advisory (e.g., not purchasing a spare to have
on hand for that "imminent" failure), then that's your perogative.  If
you can afford to have "down time" and only react to ACTUAL failures,
then that's a policy decision that YOU make.

OTOH, if there is no oil in the gearbox, the equipment isn't going to
start; if the oil sensor is defective, then *it* needs to be replaced.
But, if the gearbox is truly empty, then it needs to be refilled.
In either case, the equipment *needs* service -- now.  Operating in
this FAILED state presumably poses some risk, hence the prohibition.

[Cars have gas gauges to save the driver from "discovering" that he's
run out of fuel!]