From: ian@inf.ethz.ch (Ian)
Newsgroups: sci.nanotech
Subject: Re: Nanosystem wear and defects
Date: 7 Nov 92 03:29:25 GMT
Organization: Dept Biochemistry, University of Bristol, UK

What you describe isn't anything like the way the immune system works but
never mind it's a good idea anyway.

<few lines deleted>

> the same assemblers that built the
> active parts in the first place can be left inside the structure
<...>
> programmed to continuously tear apart and rebuild the active parts.

This is good, but what does it do to the energy/materials budget ?

> The assemblers would not necessarily have to distinguish between
> functioning and non functioning parts as it would simply be taking
> active parts out of their functional state for a short time.

The problem I see with this is that you would effectively 'reset' the
units you replaced with a consequent deletion of any internal state
that they might require for their function.  'state' could be anything
from a "METHYL_WAS_FOUND" flag to a bound half-finished substrate molecule
or part of some software that the larger machine was running.  One
possible way around this would be to use the same error detection and 
correction algorithms that people proposed in the "evolution and nanotech"
thread.  This would regard the loss of state in replacing a unit as just a
source of error in the larger machine but it must increase the costs of the 
whole process (especially in the case of half finished substrates which 
presumably get scrapped).

Another point that occurs to me is: How large are the assemblers ?  As
assembly is certainly an extremely complicated function the assemblers will
be by far the most complicated nanomachines around (for a while at least)
this implies that they will quite inappropriate for including in other 
nano-devices because, even if they are not larger, they will be much more
expensive (in energy/resources).  A corrolory (sp?) of this is that assemblers
will need a similar system themselves. (Which begins to look like a very
Godelian recursion :-)

Ways around this might be:

(i) Have internal disassemblers which remove (or disable) faulty units
    but do not replace them (disassemblers could be far smaller than 
    assemblers ?), scrap the whole device when it completely fails.

(ii) Rely on initial massive redundancy to keep the device
     going for long periods, then dissassemble it into large pieces,
     test each piece, further dissassemble the large-pieces that fail, test
     each piece . . .

(iii) Have an internal rearranger that will swap new pieces into old units
      *only* when the units do not give a *busy* signal.  This relies on an
      external source of new components.  Also have a system whereby *units*
      which fail so as to always be *busy* get suspected and replaced after
      a while (or have their neighbouring units grass on them).

(iv) Arrange units in multiples of three (this must be an old idea)
     have units display "surface-flags" which reflect their internal state.
     If a unit in a group of three shows different flags from the other two,
     replace it (this can be nested of course and it works best with 
     information processing but could be used in manufacturing if the
     threesomes were kept in synchrony).

(v) Have a system genuinely like the immune system, i.e when the device is 
    new, the immune machinery 'learns' what correct units look like later
    it replaces anything which doesn't fit the pattern.  This has the 
    disadvantage that 'subtle' internal, damage to a unit might not show.

(vi) Have multiple copies of each subsystem, monitor the efficiency of each
     copy, replace the least efficient.

Does anyone have criticisms/enhancements/more information on damage control.

btw. People earlier spoke of (I think it was called EDEC, Error Detection/Error
     Correction algorithms) (a) can someone give me a reference to a review of
     this ? (b) Do they rely on a strict distinction between the parts of the
     system that are corrected and those that do the correction ? (ie they are
     used to manage some kinds of fast memory chips, do they relay on the 
     processor running the algorithm being error free ?)  If they do, could
     they be modified for use in a system where *any* part might be hit by a
     UV ray ?  (Of course we could just shield part of the machine and have
     it run the EDEC algorithm).

[It's strange how rarely this is discussed in books on computer architecture;
 the only one I know of off hand which does is de Blasi ("Computer 
 Architecture", Addison Wesley 1990).  Also check for an article on 
 computer memories in the Jan 1985 Scientific American.
 The grandaddy article on EDC codes is Hamming, Bell System Tech. J. 29
 pp 147-60 (1950).
 --JoSH]