Reliability of Autonomous Machines

This document examines the roles of parity checking & triple redundancy in ensuring machines work as intended. This process is examined in the evolution of machinery, and provides a comparison between biotic evolution & machine evolution. We sum up the findings in the conclusion.

Introduction

How can we be confident that autonomous machines (whether built on a macro or nano scale) will work reliably on their assigned tasks? How do we counter random faults occurring, that might make them potentially harmful?

If we send autonomous machines (automatons) to a remote environment where we cannot communicate with them easily, there is a danger the machine's computer data will become corrupt. In most cases this will simply result in the computer crashing and the machine becoming useless.

Something that would be much more problematic is if the data became corrupt in such a way that the machine started to repetitively do some action incorrectly. Imagine that your machine is building Buckminster-Fullerenes (Bucky Balls) out of compounds that contain carbon. It would need to exclude any compounds that might be biological in origin.

If the line of code telling the machine to check the source of the compound becomes glitched, the machine may start to break us down for it's raw material.

Even more problems are introduced if the machine/s are self replicating (either individually or as work groups). Not only do you have the original problem but two more:

• A single error may be copied into thousands (..millions) of machines
• The code telling the machine to stop replicating after 'n' generations may be the data affected, in which case the machine may never stop producing corrupt copies.

I have been considering this problem from the viewpoint of sending machines (specifically nano's because they're so light) to neighbouring star systems to 'bootstrap' materials for an industrial base, then colonies. This brings the problem of reliability of reproduction into sharp relief.

Two of the techniques used to protect computers against data corruption lend well to the problem.

• Parity checking (borrowed from RAM/networks)
• Triple redundancy (the first I heard of this was in war planes)

Parity Checking

To each byte or data chunk you add a 'parity bit' that is:

• 0 if there are an even number of 1's.
• 1 if there are an odd number of 1's.

The diagram below demonstrates parity checking for a 4 bit data chunk (hmm.. 4 bits. Is that a 'gum' or an 'under bite'?).

The 4 bits are shown together with the parity bit on the first line. White squares represent 1 or 'False', Blue squares are 0 or 'True'. Line two shows the comparison of each bit pair, leading into the third line where the results of line two are compared to give a new parity bit. Also on line three is the projection of the original parity bit, ready for the final comparison.

In the final comparison the stored parity bit is compared to the newly calculated parity bit. If they agree the data is O.K., else the entire packet of bits is discarded (..'cos you can't figure which bit was wrong).

Unfortunately, there is a chance that both one bit in the packet, as well as the parity bit, are corrupt, though the chances of this become vanishingly small as your data reliability rises (or you add extra parity bits).

Triple Redundancy

Some military aircraft run three computers in parallel, if one becomes confused and disagrees with the other two, it's ignored. If it continues to disagree with the other two, it's shut down. The reasons for this are twofold:

• Military planes have a nasty habit of attracting gunfire, & computers don't like shrapnel.
• These craft have such complex flight surfaces that they are inherently unstable. The computers are needed to continually adjust the control surfaces to correct wobbles & tilts.

The diagram at right illustrates 4 bit data chunks calculated by 3 separate computers (the first three lines). The yellow lines leading to Red/Blue dots indicate a comparison process similar to what was shown in the parity checking example except that the comparison is done between each corresponding bit of two data chunks (... 1-1, 2-2 etc.). These lead to the Red/Blue dots indicating the same (Blue/Correct) or different (Red/Corrupt).

Only the data which compares successfully is handed to the result register shown on line 4 & acted on. This system requires one value of the data (say '0000' or '1111') to be reserved for when all three computers disagree. If you were the pilot of a plane in which that happened, this is the stage where you'd be hoping that the designers had configured that code to trigger the ejector seat...

This is fine for machines in which you have space to spare and can install 3 processors, but what about self replicating nanotechs built on such a small scale that they can only fit a single computer?

These machines can also be accommodated by instructing them to only build copies of themselves if they can confirm the 'correctness' of their own design with two other units.

Evolution

This brings me to an important point about autonomous machines and 'evolution' through mutation or corruption.

If data integrity is vital for the autonomaton then it can be achieved fairly easily by the above techniques. The evolution of life is a very different matter.

Biotic Evolution

The first soft bodied life thrived on sunlight and raw nutrients, but it didn't take long (in evolutionary timescales) for a class of biots to develop that found it easier to feed on other life. Parasites.

By whatever means, the providers attempted to repel the parasites, and developed two useful mechanisms to achieve this end. The immune system and sexual reproduction.

The immune system is a powerful defence against foreign substances and parasites, it works at various levels, the most deadly of which has white killer cells attacking any substance or cell which has a marker chemical attached. This is where sexual reproduction has it's advantage.

The marker chemical is manufactured by our immune system , on one end is a 'lock' chemical that fits a 'key' chemical on the parasite's surface. Not only does sexual reproduction pass the genes that make the locks throughout a population, it also helps to produce new variants by recombining gene pairs from the parents.

Randomness works for evolution. While there is a lot of genetic machinery that is specifically designed to repair broken DNA, there is also a lot of minor evolution going on through sex itself.

The evolution of life is not very applicable to the problems of building reliable automatons simply because the imperatives are almost completely different. One should not confuse a system that works in a random and haphazzard way (evolution) to the much more efficient ways that we have discovered to generate change.

Machine Evolution

Most animal species can communicate amongst themselves using sight, sound or smell. This ability has not been extended to communication of DNA information, most probably because life already had sexual reproduction for that purpose.

Machines do not have their own design stored within them in the form of DNA, they don't need to. The machine's design, as well as changes or developments can be stored in a single place and 'instantaneously' transmitted great distances to the place(s) of manufacture. Changes can then be made to the manufacture of every subsequent unit, without needing to permeate through the population in the way they would via sexual reproduction.

Design developments can be tested and proven at your 'home base' and sent by radio signal to a group of automatons working at a distant place. The same is true of altered aims or updated software.

If it's considered necessary to allow 'evolution' in a group of automaton's completely cut off from human supervision, the matter of reliability becomes more tricky but is still achievable.

1. Model the new development in a purpose built computer powerful enough to emulate the machine's software and hardware (both the chips and mechanical parts).
2. A group of the new machines, with limited lifespan and even more limited replicability, are built and released in a test area for assessment. The results are then analysed by the designer / emulator computer.
3. Only if both tests result in an unequivocal success does the altered design become the new standard.

Conclusion

Ensuring the reliability of autonomous machines (whether built on a macro or nano scale) will be a tedious but trivial matter.

It is vital that automatons not use the same types of random, undirected techniques through which living organisms evolve.

spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer spacer.