Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!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: Predictive failures
Date: Tue, 16 Apr 2024 15:21:25 -0700
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <uvmtlc$16539$2@dont-email.me>
References: <uvjn74$d54b$1@dont-email.me> <20240416a@crcomp.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 17 Apr 2024 00:21:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2b43e3ad6cfda17a11cedcbd329c2ac9";
	logging-data="1250409"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+3bzRrXvdOACxyNVEGnMW3"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:rEDc5J3q3FPKLXHDfwTpV8KkE4A=
In-Reply-To: <20240416a@crcomp.net>
Content-Language: en-US
Bytes: 4183

On 4/16/2024 6:25 AM, Don wrote:
> Don Y wrote:
>> Is there a general rule of thumb for signalling the likelihood of
>> an "imminent" (for some value of "imminent") hardware failure?
>>
>> I suspect most would involve *relative* changes that would be
>> suggestive of changing conditions in the components (and not
>> directly related to environmental influences).
>>
>> So, perhaps, a good strategy is to just "watch" everything and
>> notice the sorts of changes you "typically" encounter in the hope
>> that something of greater magnitude would be a harbinger...
> 
> A singular speculative spitball - the capacitive marker:
> 
>      In-situ Prognostic Method of Power MOSFET Based on Miller Effect
> 
>      ... This paper presents a new in-situ prognosis method for
>      MOSFET based on miller effect. According to the theory
>      analysis, simulation and experiment results, the miller
>      platform voltage is identified as a new degradation
>      precursor ...

With the levels of integration we now routinely encounter, this
is likely more of interest to a component vendor than an end designer.
I.e., sell a device that provides this sort of information in a
friendlier form.

Most consumers/users don't care about which component failed.
They just see the DEVICE as having failed.

The Reliability Engineer likely has more of an interest -- but,
only if he gets a chance to examine the failed device (how many
"broken" devices actually get returned to their manufacturer
for such analysis?  Even when covered IN warranty??)

When I see an LCD monitor indicating signs of imminent failure,
I know I have to have a replacement on-hand.  (I keep a shitload).
I happen to know that this particular type of monitor (make/model)
*tends* to fail in one of N (for small values of N) ways.  So,
when I get around to dismantling it and troubleshooting, I know
where to start instead of having to wander through an undocumented
design -- AGAIN.

[I've standardized on three different (sized) models to make this
process pretty simple; I don't want to spend more than a few minutes
*repairing* a monitor!]

If the swamp (evaporative) cooler cycles on, I can monitor the rate
of water consumption compared to "nominal".  Using this, I can infer
the level of calcification of the water valve *in* the cooler.
To some extent, I can compensate for obstruction by running the
blower at a reduced speed (assuming the cooler can meet the needs
of the house in this condition).  With a VFD, I could find the sweet
spot!  :>

So, I can alert the occupants of an impending problem that they might
want to address before the cooler can't meet their needs (when the
pads are insufficiently wetted, you're just pushing hot, dry air into
the house/office/business).

A "dumb" controller just looks at indoor temperature and cycles
the system on/off based on whether or not it is above or below
the desired setpoint (which means it can actually make the house
warmer, the harder it tries to close the loop!)