Groups | Search | Server Info | Login | Register
Groups > comp.arch.embedded > #32218
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Diagnostics |
| Date | 2024-10-18 17:42 -0400 |
| Organization | i2pn2 (i2pn.org) |
| Message-ID | <77k5hjprfq0ipjp6pcdd03lnph1i76ssuu@4ax.com> (permalink) |
| References | <veekcp$9rsj$1@dont-email.me> <veuggc$1l5eo$1@paganini.bofh.team> |
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
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar
Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-12 12:58 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-18 20:30 +0000
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-18 17:42 -0400
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 15:30 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 01:50 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 19:38 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 03:53 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 21:17 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-24 17:52 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-24 14:49 -0700
Re: Diagnostics David Brown <david.brown@hesbynett.no> - 2024-10-19 14:07 +0200
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-19 15:25 -0400
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-19 14:32 -0700
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-23 05:53 -0700
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 19:15 +0200
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 01:25 +0000
Re: Diagnostics David Brown <david.brown@hesbynett.no> - 2024-10-19 13:57 +0200
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 15:15 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 03:00 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-18 21:05 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-19 13:53 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-19 09:55 -0700
Re: Diagnostics antispam@fricas.org (Waldek Hebisch) - 2024-10-24 16:34 +0000
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-24 14:28 -0700
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-19 15:58 -0400
Re: Diagnostics Don Y <blockedofcourse@foo.invalid> - 2024-10-19 16:26 -0700
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 20:08 +0200
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 19:11 +0200
Re: Diagnostics George Neuner <gneuner2@comcast.net> - 2024-10-20 15:44 -0400
Re: Diagnostics Nioclásán Caileán de Ghlostéir <Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> - 2024-10-20 23:14 +0200
csiph-web