Re: Diagnostics

On Fri, 18 Oct 2024 15:30:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

Hi George,
>
[Hope all is well with you and at home]

Hi Don,

Same ol', same ol'.  Nothing much new to report.

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).

If you "know" a priori when some component will be needed, then you
can do whatever you want when it is not.  The problem is that many
uses can't be easily anticipated.

Which circles back to testing priority: if the test is interruptible
and/or resumeable, then it may be done whenever the component is
available ... as long as it won't tie up the component if and when it
becomes needed for something else.

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 you're testing memory pages, most likely you are tying up bandwidth
in the memory system and slowing progress of the real applications.

Also because you can't accurately judge the "minimum" needed.  BSD and
Linux both have this problem where a sudden burst of allocations
exhausts the pool of zeroed pages, forcing demand zeroing of new pages
prior to their re-assignment.  Slows the system to a crawl when it
happens.

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?

Because then you are watering (however briefly) when it is not
expected.  What if there was a pesticide application that should not
be wetted?  What if a person is there and gets sprayed by your test?

Properly, valve testing should be done concurrently with a scheduled
watering.  Check water is flowing when the valve should be open, and
not flowing when the valve should be closed.

 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!

Automotive is going the way of aircraft: standby running lockstep with
the primary and monitoring its data flow - able to reset the system if
they disagree, or take over if the primary fails.



The point here is that there is no "one fits all" philosophy you can
follow ... what is proper to do depends on what the (sub)system does,
its criticality, and on the components involved that may need to be
tested.