Sujet : Re: Diagnostics
De : antispam (at) *nospam* fricas.org (Waldek Hebisch)
Groupes : comp.arch.embeddedDate : 19. Oct 2024, 03:25:54
Autres entêtes
Organisation : To protect and to server
Message-ID : <vev1r0$1r4v5$1@paganini.bofh.team>
References : 1 2 3
User-Agent : tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
George Neuner <
gneuner2@comcast.net> wrote:
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.
Maybe, if you mean domain specific regulations. But there are
general EC directives. One may spent money on lawyers and
research to conclude that some protections are not required
by law. Or one may implement things like for regulated domain.
On small scale the second is likely to be cheaper.
Anyway, I do not know if there is anything specific about
washing machines, but software for them is clearly written
as if they were regulated. The same for ovens, heaters etc.
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.
IMO, "smart home" which matter have safety implications. Even
if they are not regulated now there is potential for liabilty.
And new requlations appear quite frequently.
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.
IIUC at low levels requirements are not that hard to satisfy,
especially since in most cases non-working device is deemed "safe".
-- Waldek Hebisch