Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y 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: References: 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: Content-Language: en-US Bytes: 3038 On 4/15/2024 10:32 AM, Martin Rid wrote: > Don Y 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.