From: horning@decwrl.DEC.COM (Jim Horning)
    Thanks for your comments. However, I do have to disagree with your
    cheerful assessment of the chances for REALISTIC testing of any
    SDI system or major subsystem. The problem is not that there is no
    testing that could be done, but that any substantial change in the
    system's environment is likely to provoke a new set of unexpected
    behaviors.... (Several very valid points are made about the
    difficulty of realistically testing SDI).

You are, of course, correct.  The problem is that your points could
also be (and are) made about any complex weapons systems (or indeed,
any complex system at all).  It is NEVER possible to fully test ANY
system until it is actually used in battle (and even then it can fail
in future battles).

While the size of SDI makes some testing problems harder, others may
be made easier.  Specifically, SDI operates in a far more predictable
environment that any earth based weapons system.  Enemy
countermeasures, so often cited as a problem, are a problem for ANY
battle system, and once again the possible modes of response by the
enemy need not be correlated to the size of the SDI system.  Thus I
would expect that a "realistic" (i.e. to a certain acceptable degree
of reliability) testing of the Aegis carrier defense system to be as
hard as testing SDI, even though the later is perhaps an order of
magnitude smaller than the former. (note that software and system
testing are not the same thing.)

My point was more that SDI (always excepting boost phase) could be
tested according to the same type of standards we currently use to
test other complex weapon systems (or computer systems, etc...).  That
is, the SDI testing problem is indeed a problem, but not one radically
different from those that have already been encountered (and
"solved"), or those likely to be encountered in the future.  Thus
attention should be focused on HOW to do the tests, not on decrying
that the testing problem is somehow inherently impossible to solve.

Jim [McGrath, that is]

Re: Testing SDI

    From: vax-populi!dparnas@nrl-css.arpa (Dave Parnas)
    The comments that you reported on testing SDI, proposing that we
    test it by shooting at periodic meteor swarms make me wonder how
    many of the people in our profession have trouble discriminating
    between real problems and arcade games.  Shooting at an easily
    predictable non-evasive meteor has about the same relation to the
    real job of SDI as shooting at a target in a booth at a county
    fair has to shooting at woods in heavy brush from a moving
    airplane.

It is fairly obvious that Professor Parnes did not read my original
message, nor the follow up messages.  The original message dwelt on
the COST of testing, and used meteor swarms as a simple example, not a
serious proposal for exhaustive testing (as was clear in the context
of the message).  Indeed, I specifically stated that the example given
would be good primarily for a basic test of tracking and "hard kill"
capability.

Moreover, in more recent contributions I made clear that my central
point is that testing of SDI is not somehow impossible, if you accept
that we can test such systems as Aegis.  Particularly, I think it
incredibly naive to equate size of code with system complexity.  (see
my previous message on this).

Now, one can dispute that such systems as Aegis are testable.  Or one
can hold SDI to higher reliability standards than systems such as
Aegis.  Both are defendable positions.  But the first removes SDI from
some unique class, and the second is quite debatable (depending upon
your mission definition for each system).

Jim

Re: SDI Testing

Jim,

If you think that I consider that the kind of testing that is done for
present weapons systems is acceptable for a system of the importance,
power, and risks of SDI, then we have been failing to communicate at a
very fundamental level.

The kind of risk that is acceptable for the loss of an aircraft carrier
and for the loss of all of human civilation are many orders of
magnitude apart. The complexity of SDI and Aegis (and hence the
difficulty of adequate testing) are many orders of magnitude apart. And
the military hasn't done so well at testing in the past (DIVAD, Bradley
Fighting Vehicle, plus the examples you cite) that I am willing to
trust them to decide what testing would suffice here.

I do not consider arcade games to be a suitable model for this
excercise.

Jim H.

Dec. IEEE TSE: Special Issue on Software Reliability--Part I

[This note is primarily for that small fraction of Risks that may not
be regular readers of IEEE Transactions on Software Engineering.  --Jim H.]

The December 1985 issue of TSE is devoted to software reliability. As
has been noted many times in this forum, unreliable software is one of
the principal sources of risks from computer systems.

A few things that caught my eye in this issue:

  "The occurrence of major software failures is strongly correlated with the
  type and level of workload prior to the occurrence of a failure.  This
  indicates that software reliability models cannot be considered
  representative unless the system workload environment is taken into account.
  The effect of workload on software reliability is highly nonlinear; i.e.,
  there is a threshold beyond which the software reliability rapidly
  deteriorates. ... Although we may intuitively expect to find a higher
  software error rate with higher workload (partly attributable to greater
  execution), there appears to be no fundamental reason why both software and
  hardware should exhibit a similar nonlinear increase in the load-hazard with
  increasing workload."

  "Recognizing the problem is only the first step; knowing what to do to
  achieve high confidence software still remains elusive. This is especially
  true in the area of software reliability, one of the prime factors affecting
  confidence (or lack of it) in software systems.  Current DOD development
  programs are unable to achieve satisfactory software reliability in a
  consistent fashion because of the lack of understanding of what conditions
  truly affect reliability. This situation is compounded when you consider
  that software reliability requirements for future DOD systems will be much
  higher as functional demands on the software become more complex, as
  criticality of the software increases and as system components become more
  distributed."

  "Abstract--When a new computer software package is developed and all
  obvious erros [sic] removed, a testing procedure is often put into
  effect to eliminate the remaining errors in the package."

  "Successful Missions ... Proportion of fault-tolerant runs which
  completed without failing: 56 percent; Proportion of nonfault-tolerant
  runs which completed without failing: 47 percent."

  "An intensity function, called the intensity of coincident errors, has
  a central role in this analysis. This function describes the propensity
  of programmers to introduce design faults in such a way that software
  components fail together when executing in the application environment.
  ... We study some differences between the coincident errors model ...
  and the model that assumes independent failures of component verions [sic].

  "Certain intensity functions can result in an N-version system, on
  average, being more prone to failure than a single software component.
  ... The effects of coincident errors, as a minimum, required an
  increase in the number of software components greater than would be
  predicted by calculations using the combinatorial method which assumes
  independence. ... It is clear we need empirical data to truly assess
  the effects of these errors on highly reliable software systems."

Re: Masquerading

In Risks Volume 1 Issue 34 it was suggested that a "trusted path" could
be implemented by having trusted terminal driver software recognize "a
combination of keystrokes from the user that would be defined to mean
'enter trusted path'." I would like to suggest that if one were to
implement such a mechanism that one should make the "enter trusted path"
signal be a single keystroke, i.e., one character or the out-of-band
BREAK/ATTENTION key signal, not a "combination of keystrokes".

The reason is that it would be relatively easy for a malicious program
to interfere with a multi-character signal.  For example:  most
terminals can be made to send an answerback string to the host, a
program that is trying to not be defeated by an "enter trusted path"
signal could be constantly be sending answerback requests to the
terminal.  The terminal device driver would then not be able to
recognize the combination of keystrokes that make up the "enter trusted
path" signal due to the interleaving of answerback messages.

I suggest to anyone implementing such a trusted path mechanism that they
use the out-of-band BREAK/ATTENTION key signal for the "enter trusted
path" signal so that the user and applications will still have the full
character set to work with.  Whatever character/signal is used one
should not be able to change or disable it.

                              Tague@CISL

Search RISKS using swish-e 

Report problems with the web pages to the maintainer