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 19:19:06 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <uvkn71$ngqi$2@dont-email.me>
References: <uvjn74$d54b$1@dont-email.me> <uvjobr$dfi2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 16 Apr 2024 04:19:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8f873457a009428ae193cacdeebfb978";
	logging-data="770898"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18W3IJ/2ORji0YIiPybslms"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:0wiye+BNTthmxUy/cmntMs3YdGs=
In-Reply-To: <uvjobr$dfi2$1@dont-email.me>
Content-Language: en-US
Bytes: 3038

On 4/15/2024 10:32 AM, Martin Rid wrote:
> Don Y <blockedofcourse@foo.invalid> Wrote in message:r
>> Is there a general rule of thumb for signalling the likelihood ofan "imminent" (for some value of "imminent") hardware failure?I suspect most would involve *relative* changes that would besuggestive of changing conditions in the components (and notdirectly related to environmental influences).So, perhaps, a good strategy is to just "watch" everything andnotice the sorts of changes you "typically" encounter in the hopethat something of greater magnitude would be a harbinger...
> 
> 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?

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

You can include mechanisms to verify outputs are what you
*intended* them to be (in case the output drivers have shit
the bed).

You can, also, do sanity checks that ensure values are never
what they SHOULDN'T be (this is commonly done within software
products -- if something "can't happen" then noticing that
it IS happening is a sure-fire indication that something
is broken!)

[Limit switches on mechanisms are there to ensure the impossible
is not possible -- like driving a mechanism beyond its extents]

And, where possible, notice second-hand effects of your actions
(e.g., if you switched on a load, you should see an increase
in supplied current).

But, again, these are more helpful in detecting FAILED items.