From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: ***
X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,885dab3998d28a4
X-Google-Attributes: gid103376,public
X-Google-Thread: 107079,eca28648989efca9
X-Google-Attributes: gid107079,public
From: "Dann Corbit" <a-cnadc@microsoft.com>
Subject: Re: Ariane 5 failure
Date: 1996/09/29
Message-ID: <01bbad9a$06dc72a0$2bac399d@v-cnadc1>#1/1
X-Deja-AN: 185916417
distribution: inet
references: <agrapsDy4oJH.29G@netcom.com> <1780E8471.KUNNE@frcpn11.in2p3.fr>
 <mheaney-ya023180002609962252500001@news.ni.net>
 <1996Sep27.023246.18774@jarvis.cs.toronto.edu>
 <DyE738.Hzz@beaver.cs.washington.edu>
content-type: text/plain; charset=ISO-8859-1
organization: Microsoft Corporation
mime-version: 1.0
newsgroups: comp.lang.ada,sci.math.num-analysis
Date: 1996-09-29T00:00:00+00:00
List-Id: <comp.lang.ada>


I propose a software IC metaphor for high
reliability projects. (And all eventually).

Currently, the software industry goes by
what I call a "software schematic" metaphor.
We put in components that are tested, but
we do not necessarily know the performance
curves.

If you look at S. Moshier's code in the
Cephes Library on Netlib, you will see that
he offers statistical evidence that his 
programs are robust.  So you can at least
infer, on a probability basis, what the odds
are of a component failing.  So instead of
just dropping in a resistor or a transistor,
we read the little gold band, or the spec
on the transistor that shows what voltages
it can operate under.
For simple components with, say, five bytes
of input, we could exhaustively test all 
possible inputs and outputs.  For more
complicated procedures with many bytes of
inputs, we could perform probability testing,
and test other key values.

Imagine a database like the following:
TABLE: MODULES
int      ModuleUniqueID
int      ModuleCategory
char*60  ModuleName
char*255 ModuleDescription
text     ModuleCode
text     TestRoutineUsed
bit      CompletelyTested

TABLE: TestResults (many result sets for one module)
int      TestResultUniqueID
int      ModuleUniqueID
char*60  OperatingSystem
char*60  CompilerUsed
binary   ResultChart
text     ResultDescription
float    ProbabilityOfFailure
float    RmsErrorObserved
float    MaxErrorObserved

TABLE: KnownBugs  (many known bugs for one module)
int      KnownBugUniqueID
int      ModuleUniqueID
char*60  KnownBugDescription
text     BugDefinition
text     PossibleWorkAround

Well, this is just a rough outline, but the value of
a database like this would be obvious.  This could
easily be improved and expanded. (More domain tables,
tables for defs of parameters to the module, etc.)

If we had a tool like that, we would be using
software IC's, not software schematics.
-- 
"I speak for myself and all of the lawyers of the world"
If I say something dumb, then they will have to sue themselves.