Re: Diagnostics

Liste des GroupesRevenir à ca embedded 
Sujet : Re: Diagnostics
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : comp.arch.embedded
Date : 19. Oct 2024, 00:30:54
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <veunj9$3gbqs$2@dont-email.me>
References : 1 2 3
User-Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Hi George,
[Hope all is well with you and at home]
On 10/18/2024 2:42 PM, George Neuner wrote:
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.
But, if you *know* when certain aspects of a device will be "called on",
you can take advantage of that to schedule diagnostics when the device is
not "needed".  And, in the event that some unexpected "need" arises,
can terminate or suspend the testing (possibly rendering the effort
moot if it hasn't yet run to a conclusion).
E.g., I scrub freed memory pages (zero fill) so information doesn't
leak across protection domains.  As long as some minimum number
of *scrubbed* pages are available for use "on demand", why can't
I *test* the pages yet to be scrubbed?
If I don't *expect* a car to pull up and call for the garage door
to be opened, why can't I play with the lighting to verify that
the cameras located within *notice* changes?
If there is no anticipated short term need for irrigation, why
can't I momentarily activate individual valves and watch to see that
the expected amount of water is flowing?
If a node is powered down due to lack of expected immediate need,
why not power it *up* and run diagnostics on it?  Powering it back
down once completed -- *or*, aborting the diagnostics if the node
is called on to be powered up?

 To ensure 100%
functionality at all times effectively requires use of redundant
hardware - which generally is too expensive for a non safety critical
device.
Apparently, there is noise about incorporating such hardware into
*automotive* designs (!).  I would have thought the time between
POSTs would have rendered that largely ineffective.  OTOH, if
you imagine a failure can occur ANY time, then "just after
putting the car in gear" is as good (bad!) a time as any!

Date Sujet#  Auteur
12 Oct 24 * Diagnostics30Don Y
18 Oct 24 `* Re: Diagnostics29Waldek Hebisch
18 Oct 24  +* Re: Diagnostics15George Neuner
19 Oct 24  i+* Re: Diagnostics12Don Y
19 Oct 24  ii+* Re: Diagnostics6Waldek Hebisch
19 Oct 24  iii`* Re: Diagnostics5Don Y
19 Oct 24  iii `* Re: Diagnostics4Waldek Hebisch
19 Oct 24  iii  `* Re: Diagnostics3Don Y
24 Oct19:52  iii   `* Re: Diagnostics2Waldek Hebisch
24 Oct23:49  iii    `- Re: Diagnostics1Don Y
19 Oct 24  ii+- Re: Diagnostics1David Brown
19 Oct 24  ii+* Re: Diagnostics3George Neuner
19 Oct 24  iii`* Re: Diagnostics2Don Y
23 Oct 24  iii `- Re: Diagnostics1Don Y
20 Oct 24  ii`- Re: Diagnostics1Nioclásán Caileán de Ghlostéir
19 Oct 24  i+- Re: Diagnostics1Waldek Hebisch
19 Oct 24  i`- Re: Diagnostics1David Brown
19 Oct 24  `* Re: Diagnostics13Don Y
19 Oct 24   `* Re: Diagnostics12Waldek Hebisch
19 Oct 24    `* Re: Diagnostics11Don Y
19 Oct 24     +* Re: Diagnostics4Waldek Hebisch
19 Oct 24     i`* Re: Diagnostics3Don Y
24 Oct18:34     i `* Re: Diagnostics2Waldek Hebisch
24 Oct23:28     i  `- Re: Diagnostics1Don Y
19 Oct 24     +* Re: Diagnostics3George Neuner
20 Oct 24     i`* Re: Diagnostics2Don Y
20 Oct 24     i `- Re: Diagnostics1Nioclásán Caileán de Ghlostéir
20 Oct 24     `* Re: Diagnostics3Nioclásán Caileán de Ghlostéir
20 Oct 24      `* Re: Diagnostics2George Neuner
20 Oct 24       `- Re: Diagnostics1Nioclásán Caileán de Ghlostéir

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal