Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: George Neuner Newsgroups: comp.arch.embedded Subject: Re: Diagnostics Date: Sat, 19 Oct 2024 15:25:43 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <77k5hjprfq0ipjp6pcdd03lnph1i76ssuu@4ax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: i2pn2.org; logging-data="2779282"; mail-complaints-to="usenet@i2pn2.org"; posting-account="h5eMH71iFfocGZucc+SnA0y5I+72/ecoTCcIjMd3Uww"; User-Agent: ForteAgent/8.00.32.1272 X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 4471 Lines: 85 On Fri, 18 Oct 2024 15:30:54 -0700, Don Y 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 >> 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.