Deutsch English Français Italiano |
<veuggc$1l5eo$1@paganini.bofh.team> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!2.eu.feeder.erje.net!feeder.erje.net!nntp.comgw.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail From: antispam@fricas.org (Waldek Hebisch) Newsgroups: comp.arch.embedded Subject: Re: Diagnostics Date: Fri, 18 Oct 2024 20:30:06 -0000 (UTC) Organization: To protect and to server Message-ID: <veuggc$1l5eo$1@paganini.bofh.team> References: <veekcp$9rsj$1@dont-email.me> Injection-Date: Fri, 18 Oct 2024 20:30:06 -0000 (UTC) Injection-Info: paganini.bofh.team; logging-data="1742296"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A"; User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64)) X-Notice: Filtered by postfilter v. 0.9.3 Bytes: 2314 Lines: 32 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. -- Waldek Hebisch