home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / realtime / 1050 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.7 KB
  1. Path: sparky!uunet!munnari.oz.au!nutmeg!pjm
  2. Newsgroups: comp.realtime
  3. Subject: Re: Where to stick the watchdog? 
  4. Message-ID: <1992Sep4.085016.3717@darwin.ntu.edu.au>
  5. From: pjm@nutmeg.cs.ntu.edu.au (Phil Maker)
  6. Date: 4 Sep 92 08:50:16 +0900
  7. Distribution: world
  8. Organization: Computer Science, Northern Territory University, Australia
  9. Keywords: Watchdogs
  10. Nntp-Posting-Host: nutmeg.ntu.edu.au
  11. Originator: pjm@nutmegLines: 67
  12. Lines: 67
  13.  
  14. > Recently I had an argument (discussion) with some co-workers regarding where
  15. > is an appropriate place to kick a watchdog timer inside an application program.
  16. > 
  17. > Their side was 'stick it in the lowest level routine in a non-kernal based
  18. > application, or stick it in the null task in a real-time kernal.'
  19. > 
  20. > I have problems with either solution. 
  21. > [ Lots of reasonable problems deleted ]
  22.  
  23. My suggestion for kicking watchdogs would be a little more complicated.
  24. (And I don't like watchdogs anyway but ...(And I don't like complicated 
  25. solutions but ..)).
  26.  
  27. First lets determine what errors we would like to catch in the best of
  28. all possible worlds.
  29.  
  30. * Processor interrupts disabled or kernel crashed so that some
  31.   processes cannot be executed. 
  32.  
  33.     Use a low priority timer interrupt to start a low priority
  34.     process which actually kicks the dog. (This provides a better
  35.     test of the kernel and general health of the system).
  36.     Of course timing deadlines come in to this but they are
  37.     easy to solve aren't they. (:-))
  38.  
  39. * Code or data store trashed by cosmic rays, software errors and hardware
  40.   features.
  41.  
  42.     Have a self test process that checksums the code every whatever
  43.     pico seconds. The data space can have its integrity checked by
  44.     having a data OK function provided by each module (or class). 
  45.     This is very useful for testing and debugging and if you have
  46.     the space in the product you could actually check some 
  47.     of the data structures out on the fly to see that they
  48.     meet the designers beliefs. 
  49.  
  50. * Checking that the system is actually working, i.e. making progress 
  51.   towards the goals of the system.
  52.  
  53.     For example every hard real time event put a counter in the
  54.     system. If these do NOT increase at the appropriate
  55.     frequency then something is wrong. The test for these
  56.     increases would done in the watchdog process.
  57.     Intermittent events require the use of flags etc to
  58.     determine if progress should be increasing but the method
  59.     still applies. 
  60.  
  61. Final note: any rational engineer would of course implement a small 
  62.     subset of the above. Error detection and correction is
  63.     one of the most difficult areas of real time systems. 
  64.     The best approach is to avoid the errors in the first place
  65.     and have outside safety systems. (Not reliablity).,
  66.  
  67.  
  68.                 Phil Maker
  69.  
  70.                 N.T. University
  71.                 Darwin, Australia.
  72.                 
  73.  
  74.  
  75.  
  76.  
  77.  
  78.     
  79.         
  80.  
  81.