Sujet : Re: Diagnostics
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : comp.arch.embeddedDate : 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!