tic missiles impotent and obsolete" and th eters.

The results of the scientific and engineer show the expected level of effectiveness a ticipated system. These parameters will when the future President and a future ( ployment.

In a letter to the SDIO director, Profes sulting the highly accomplished softw Brooks. On October 30, 1985, Dr. Brook mittee:

I see no reason why I or any other competent ager than I am-and there are a lot of themsystem.

In the same letter Professor Parn: Brooks', opinions with an open min wise.

There are those who claim that software. We agree that they canne that they can. We agree with them.

Again, I thank you for the opp opinions regarding the software is questions.

Senator WARNER. Thank you v encouraging report and unequivo Gentlemen, for the benefit of t who have joined us, Senator Ha prehensive and valuable appro witnesses provided their direc into our customary round of the first round.

We will now hear from Dr. :

STATEMENT OF DAVID PAN PARTMENT OF COMPUTE RIA, BRITISH COLUMBIA Mr. PARNAS. I would like and giving me a chance to t very important to the defer

Senator WARNER. If I m: out the benefit of your cha of value to us, we had bet lowed by members of the. Mr. PARNAS. May I p chart.

Senator WARNER. Well. a minute here.

Gentlemen, I am tol pended to the documer. ness, Dr. Parnas. I ima. vided in your testimon subcommittee.

Gentlemen, do you s

one for that purmmittee to underere without softthe sensors and Itware will be the -member is that if

ee us gain from a Reagan promised, ware. If we do not ve will make deciterrent with both a

work and redouwould really like to sertware to be pernyfe.

cow it is not perfect. I

know is what its

: can fail. I want to

essional life demandsure. I began my profes

that engineers make produce reliable sysgs that our intuition

exhaustive case analthe complete system. at none of those things have lots of emperical military or nonmili2 we do not have any of

designed for something y well to software. AÏ proximations that are y the numerical calcula

when we do not have us because there are ... statistical calculations eal confidence that catahousands of years.

en first put into use, their ever really know that you

ut a bug in a telephone arty 2 hours. It was suput it failed in the first 2 ave been in there for

ld never build are a number

i can build it and here is the general quality

it sometimes allows it to be untrustworthy. For none system. No one objects when a call occasioney only consider the system to be down if all calls gh for an appreciable period of time.

Deen extensive use under actual conditions before nt of the software. I have worked as a consultant for abs and I know that before anything is put into per. they go through a period called a "soak" in which software with real data in the real world connected to

nent.

very important thing is that the operating conditions of are have to be controlled and predictable. The telephone s very, very careful to make sure you cannot connect quipment. There are all kinds of detailed standards to con

it.

hardware reliability is assured through redundancy and h knowing that coordinated failures are very, very unlikely. up manual systems are available in many cases when needed eople just wait a little while. That kind of thing happens with shuttle. It happens with the telephone network. Unfortunately, none of those things hold for SDI.

Now, there are more things that make SDI much more difficult an other projects.

First of all, we do not know exactly what the job is and we cannot know the mathematical functions that are required of the software because they are controlled by the other side, by the Russians. It is possible for them to change the problem and us not know it, so we can never be sure that we have met the requirements; we can never be sure that we know what the exact requirements are.

Space based ABM systems have distributed computing like the telephone company, but because the thing is in space and subject to coordinated attack by sophisticated attackers, both the channel and hardware are going to be unreliable.

The telephone network has physical distribution of data, but it does not have to be redundant and consistent in real time or even close to it. We know from military systems that have tried to do distributed data that sometimes we can have battle alerts because we think there are more ships around than there are because the data base gets out of date and inconsistent.

Redundancy, which is the key to reliability, is, first of all, unusually expensive in space.

Second, redundancy works when you are worried about independent failures of components, for example, a manufacturing problem. Redundancy does not work when you have to worry about design failures because design failures may be in the redundant code itself. It does not give you the kind of assurance in software that it does in hardware because all software errors are design

errors.

It turns out if you look closely at how these military systems are done, including the A-7 software with which I am now intimately familiar, you find they are based on assumptions about how the

There are a number of things that have to be done for that purpose. The most important thing for the subcommittee to understand today is that none of these things can be done without software. Software has to process the data collected by the sensors and use it to make decisions and aim the weapons. Software will be the glue that holds the whole system together.

The point that I think is really important to remember is that if we can gain the things that I would like to see us gain from a project of this kind, the thing that President Reagan promised, that it is very important that we trust that software. If we do not trust the software, if we do not trust the system, we will make decisions as if it were not there, continue the deterrent with both a shield and missile-building program.

They will have to assume that the shield might work and redouble their efforts. Now, one of the things that I would really like to impress on you is that I do not expect the SDI software to be perfect. I have been working with real software all my life.

I drive a car every day that I trust and I know it is not perfect. I just want it to be trustworthy. What I want to know is what its limits are, when it can succeed, and when it can fail. I want to have confidence it will not fail catastrophically.

I have never in any argument or in my professional life demanded perfection in any product including software. I began my professional life as an engineer. I have been taught that engineers make mistakes and there are three ways we can produce reliable systems. There are ways of validating the designs that our intuition comes up with.

The three ways are mathematical analysis, exhaustive case analysis, a very prolonged, very realistic testing of the complete system. What I would like to convince you of is that none of those things is possible for software. It turns out that we have lots of emperical evidence that software is the last part of any military or nonmilitary system to be ready. The reason is that we do not have any of those three validation methods.

The mathematical tools that we have are designed for something called continuous functions, and do not apply well to software. All proofs of correctness of programs make approximations that are not valid for this kind of software, especially the numerical calculations.

The exhaustive case analysis that we use when we do not have mathematical tools is often not available to us because there are too many cases. It is easy to come up with statistical calculations that show that thorough testing to instill real confidence that catastrophic failures will not occur can require thousands of years.

Software systems are never reliable when first put into use, their reliability increases after use, but you never really know that you have found the last bug.

I was told the other day a story about a bug in a telephone system that caused a switch to fail for nearly 2 hours. It was supposed to be down 2 hours in 40 years, but it failed in the first 2 years of use. It was a bug that turned out to have been in there for the whole 2 years.

That kind of argument may sound as if we could never build trustworthy software and that is not the case. There are a number

of reasons why you can build it and here is the general quality they all have.

The requirement sometimes allows it to be untrustworthy. For example, a telephone system. No one objects when a call occasionally gets lost. They only consider the system to be down if all calls cannot get through for an appreciable period of time.

There has been extensive use under actual conditions before final deployment of the software. I have worked as a consultant for AT&T Bell Labs and I know that before anything is put into permanent use, they go through a period called a "soak" in which they test the software with real data in the real world connected to real equipment.

Another very important thing is that the operating conditions of the software have to be controlled and predictable. The telephone system is very, very careful to make sure you cannot connect faulty equipment. There are all kinds of detailed standards to control that.

The hardware reliability is assured through redundancy and through knowing that coordinated failures are very, very unlikely. Backup manual systems are available in many cases when needed or people just wait a little while. That kind of thing happens with the shuttle. It happens with the telephone network.

Unfortunately, none of those things hold for SDI.

Now, there are more things that make SDI much more difficult than other projects.

First of all, we do not know exactly what the job is and we cannot know the mathematical functions that are required of the software because they are controlled by the other side, by the Russians. It is possible for them to change the problem and us not know it, so we can never be sure that we have met the requirements; we can never be sure that we know what the exact requirements are.

Space based ABM systems have distributed computing like the telephone company, but because the thing is in space and subject to coordinated attack by sophisticated attackers, both the channel and hardware are going to be unreliable.

The telephone network has physical distribution of data, but it does not have to be redundant and consistent in real time or even close to it. We know from military systems that have tried to do distributed data that sometimes we can have battle alerts because we think there are more ships around than there are because the data base gets out of date and inconsistent.

Redundancy, which is the key to reliability, is, first of all, unusually expensive in space.

Second, redundancy works when you are worried about independent failures of components, for example, a manufacturing problem. Redundancy does not work when you have to worry about design failures because design failures may be in the redundant code itself. It does not give you the kind of assurance in software that it does in hardware because all software errors are design

errors.

It turns out if you look closely at how these military systems are done, including the A-7 software with which I am now intimately familiar, you find they are based on assumptions about how the

software is going to be used. There are real time schedules built into it.

Unfortunately, that makes them subject to overloading, in a very simple way, by an enemy that has any inkling as to what kind of schedules are built into it.

A really critical factor is that there are very limited opportunities for realistic testing of the whole system.

All of the networks of which you will hear and all of the successful software of which you will hear, could be tested because of the fact that most of the components are controlled by us, we have been able to simulate them during testing. However, we know that after we do component testing and simulations and we put a system out in the field, it invariably fails because something comes up that we did not anticipate.

That kind of thing, for example, leads airplanes to crash even though the software tested out all right in the preflight test. There may be interaction between hardware and software that was not anticipated.

Finally, this software is only going to be used once and for a short period of time, if it is ever to be used at all.

I have been inside of trucks that have software computers that served in Vietnam. All over the walls were "debugging notes." The manufacturers had to put two civilian programmers in the field in Vietnam in order to correct the programs because they could not find all the bugs at home in the laboratory and test it. We would not have that kind of opportunity with SDI.

It is often said that this system is going to be the largest realtime system ever made. None of my arguments are based on those estimates. They are based on the fact we cannot know the requirements that we assume are correct.

Now, it is often said these arguments would apply to other military softwear. I have given you a list of technical differences and they are very important technical differences.

I can give you list of nontechnical differences as well. This is an all-in-one basket proposal, all eggs in one basket. If we really follow the reasoning of President Reagan, then we would end up saying we are depending on this completely and that is different. In all cases we use redundant weapons and techniques.

SDI is different because it will only be used once. All the military software we now find reliable has been used several times and we have gotten the bugs out of it that way.

SDI is different because we cannot test it under real battle conditions and because we have never had this kind of distributed system and because in this particular weapon system the software is so vital it plays a more vital role than software any other weapon system we have successfully built.

Finally, SDI is different because our enemy will be forced to focus so much attention on it.

One of the things that scares me if this system, and one of the reasons I believe in the long run no one will ever trust this system is because it will be extremely subject to a kind of blackmail.

One of the things we know from game playing experiments with computers is if you know the program of the other computer, you can always beat it. Even as a mere human being, if you know the