Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: comp.arch.embedded
Subject: Diagnostics
Date: Sat, 12 Oct 2024 12:58:02 -0700
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <veekcp$9rsj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 12 Oct 2024 21:58:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d63472ff6b107acd52ba8ce0a97b11d3";
	logging-data="323475"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19AZ/SycQMpck3vH2f9cuJd"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:XkROS5PHyVEukxD/FjpFzu4utx8=
Content-Language: en-US
Bytes: 1956

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?