Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.arch.embedded
Subject: Re: Diagnostics
Date: Fri, 18 Oct 2024 17:42:44 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <77k5hjprfq0ipjp6pcdd03lnph1i76ssuu@4ax.com>
References: <veekcp$9rsj$1@dont-email.me> <veuggc$1l5eo$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: i2pn2.org;
	logging-data="2648522"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="h5eMH71iFfocGZucc+SnA0y5I+72/ecoTCcIjMd3Uww";
User-Agent: ForteAgent/8.00.32.1272
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3267
Lines: 53

On Fri, 18 Oct 2024 20:30:06 -0000 (UTC), antispam@fricas.org (Waldek
Hebisch) wrote:

>Don Y <blockedofcourse@foo.invalid> wrote:
>> Typically, one performs some limited "confidence tests"
>> at POST to catch gross failures.  As this activity is
>> "in series" with normal operation, it tends to be brief
>> and not very thorough.
>> 
>> Many products offer a BIST capability that the user can invoke
>> for more thorough testing.  This allows the user to decide
>> when he can afford to live without the normal functioning of the
>> device.
>> 
>> And, if you are a "robust" designer, you often include invariants
>> that verify hardware operations (esp to I/Os) are actually doing
>> what they should -- e.g., verifying battery voltage increases
>> when you activate the charging circuit, loopbacks on DIOs, etc.
>> 
>> But, for 24/7/365 boxes, POST is a "once-in-a-lifetime" activity.
>> And, BIST might not always be convenient (as well as requiring the
>> user's consent and participation).
>> 
>> There, runtime diagnostics are the only alternative for hardware
>> revalidation, PFA and diagnostics.
>> 
>> How commonly are such mechanisms implemented?  And, how thoroughly?
>
>This is strange question.  AFAIK automatically run diagnostics/checks
>are part of safety regulations.  Even if some safety critical software
>does not contain them, nobody is going to admit violationg regulations.  
>And things like PLC-s are "dual use", they may be used in non-safety
>role, but vendors claim compliance to safety standards.

However, only a minor percentage of all devices must comply with such
safety regulations.  

As I understand it, Don is working on tech for "smart home"
implementations ... devices that may be expected to run nearly
constantly (though perhaps not 365/24 with 6 9's reliability), but
which, for the most part, are /not/ safety critical.

WRT Don's question, I don't know the answer, but I suspect runtime
diagnostics are /not/ routinely implemented for devices that are not
safety critical.  Reason: diagnostics interfere with operation of
<whatever> they happen to be testing.  Even if the test is at low(est)
priority and is interruptible by any other activity, it still might
cause an unacceptable delay in a real time situation.  To ensure 100%
functionality at all times effectively requires use of redundant
hardware - which generally is too expensive for a non safety critical
device.

YMMV.
George