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: Mon, 15 Apr 2024 22:32:04 -0700
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <uvl2gr$phap$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 16 Apr 2024 07:32:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8f873457a009428ae193cacdeebfb978";
	logging-data="836953"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19dCPpNJf4+9Zet4plQgPUI"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:F0mkyhDN1u/Bu5FYxIl9+pP6Yas=
In-Reply-To: <uvkrig$30nb$1@nnrp.usenet.blueworldhosting.com>
Content-Language: en-US
Bytes: 6076

On 4/15/2024 8:33 PM, Edward Rawde wrote:

[Shouldn't that be Edwar D rawdE?]

>>> Current and voltages outside of normal operation?
>>
>> I think "outside" is (often) likely indicative of
>> "something is (already) broken".
>>
>> But, perhaps TRENDS in either/both can be predictive.
>>
>> E.g., if a (sub)circuit has always been consuming X (which
>> is nominal for the design) and, over time, starts to consume
>> 1.1X, is that suggestive that something is in the process of
>> failing?
> 
> That depends on many other unknown factors.
> Temperature sensors are common in electronics.
> So is current sensing. Voltage sensing too.

Sensors cost money.  And, HAVING data but not knowing how to
USE it is a wasted activity (and cost).

Why not monitor every node in the schematic and compare
them (with dedicated hardware -- that is ALSO monitored??)
with expected operational limits?

Then, design some network to weight the individual
observations to make the prediction?

>> Note that the goal is not to troubleshoot the particular design
>> or its components but, rather, act as an early warning that
>> maintenance may be required (or, that performance may not be
>> what you are expecting/have become accustomed to).
> 
> If the system is electronic then you can detect whether currents and/or
> votages are within expected ranges.
> If they are a just a little out of expected range then you might turn on a
> warning LED.
> If they are way out of range then you might tell the power supply to turn
> off quick.
> By all means tell the software what has happened, but don't put software
> between the current sensor and the emergency turn off.

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).

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!

A smoke detector that beeps once a day risks not being heard
(what if the occupant "works nights"?).  A smoke detector
that beeps a month in advance of the anticipated failure (and
requires acknowledgement) risks being forgotten -- until
it is forced to beep more persistently (see above).

> Be aware that components in monitoring circuits can fail too.

Which is why hardware interlocks are physical switches -- yet
can only be used to protect against certain types of faults
(those that are most costly -- injury or loss of life)

>> But, again, these are more helpful in detecting FAILED items.
> 
> What system would you like to have early warnings for?
> Are the warnings needed to indicate operation out of expected limits or to
> indicate that maintenance is required, or both?
> Without detailed knowledge of the specific sytem, only speculative answers
> can be given.

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!)

E.g., when making tablets, it is possible that a bit of air will
get trapped in the granulation during compression.  This is dependant
on a lot of factors -- tablet dimensions, location in the die
where the compression event is happening, characteristics of the
granulation, geometry/condition of the tooling, etc.

But, if this happens, some tens of milliseconds later, the top will "pop"
off the tablet.  It now is cosmetically damaged as well as likely out
of specification (amount of "active" present in the dose).  You want
to either be able to detect this (100% of the time on 100% of the tablets)
and dynamically discard those units (and only those units!).  *OR*,
identify the characteristics of the process that most affect this condition
and *monitor* for them to AVOID the problem.

If that means replacing your tooling more frequently (expensive!),
it can save money in the long run (imagine having to "sort" through
a million tablets each hour to determine if any have popped like this?)
Or, throttling down the press so the compression events are "slower"
(more gradual).  Or, moving the event up in the die to provide
a better egress for the trapped air.  Or...

TELLING the user that this is happening (or likely to happen, soon)
has real $$$ value.  Even better if your device can LEARN which
tablets and conditions will likely lead to this -- and when!