Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
In Risks 2.7, J. Giles speculates:
>Has expert system technology been thought of as a fix for this problem?
>... a really fast computer ... could monitor all those inputs which aren't
>under the direction of human flight controllers...
>Are expert systems yet advanced enough to make this worthwhile?
Unfortunately, expert systems developed to handle such an occurrence would
have to be based on a foreknowledge of the relationship of the various
anomalies that occurred in the shuttle disaster. I seriously doubt that
most competent systems safety engineers could have predicted the occurrence
even with a full knowledge of the anomalies that occurred. Development of
such an expert system would likely have to be based on that type of
knowledge. However, expert systems aside, I am amazed that the NASA systems
safety people would permit a multiple section rocket motor to be manufactured
at one location and assembled at another. Misfortune has shown us in the past
that these composite structure solid rockets have some very unique and
undesirable properties. It will be interesting to see exactly where the
failure occurred in the shuttle's SRB if in fact it did fail. If the failure
occurred at some location other than the suspect joint, chalk another one
up to experience.
Michael Brown
Well, it's certainly possible to set up some sort of expert system that
would monitor incoming telemetry and issue warnings in case of
possibly-dangerous combinations of unusual conditions. However,
I can see a couple of difficulties involved here:
1- There are some conflicts re the amount of data that you want to
feed into the expert-system tool. Certainly, the more data that
is available (from many different classes of sensors), the smaller
the chance that the tool won't have the information needed to
detect the problem. [For example, Challenger was equipped with
far fewer sensors on the SRB than was Columbia during its tryoug
flights].
But... as you increase the number of individual sensors, and the
amount of data (# of different classes of data, especially), you
necessarily increase the number of rules in the system, and the
amount of crunchpower necessary to step through the rules and
determine whether any conclusions need to be brought to the
attention of the controllers. It doesn't do you much good to
receive a warning saying "Engine failure is probable, based on
conditions xxx and yyy" if you don't get the warning in time to
do anything about it.
In my [very limited] experience, very few if any existing expert
systems are capable of handling large amounts of real-time data;
the ones that I've seen tend to be somewhat sluggish. I don't
doubt that it would be possible to build special-purpose hardware
that would support such a system... but I don't believe it has been
done yet.
2- As I understand them, expert systems are designed to reproduce (or
mimic) the sort of what-if and maybe-then decision sequences that
an expert would go through when analyzing a particular sort of
problem. They work by encoding (in explicit form) the steps and
conclusion that an expert would use. A large part of the work
involved in developing an expert system is sitting down with the
expert(s), and assisting them in encoding their (often implicit and
unspoken) rules into rigorous form.
All well and good... BUT... the expert system's "expertise" is
entirely limited by the completeness of the rules that are used to
construct it. One cannot assume that an expert system will be able
to detect or diagnose a situation that has never been encountered
before... it may do so, if the rules were complete enough and if the
situation is similar to one that has occurred before, but you don't
want to bet your life on it!
Only the simplest expert systems can ever be considered to be
"complete". When solving a complex, real-world problem (such as
"Is the shuttle's current behavior normal?"), the best that you
can expect is that some useful fraction of all possible situations
will be analyzed in a meaningful fashion. Expert systems tend to
grow and evolve as they are used... just as a human expert's
capabilities do... and both humans and expert systems will tend to
misdiagnose situations that fall outside of their current knowledge
base.
3- Even if an expert system reacts quickly and accurately enough to give
a meaningful warning ("SRBs leaking, ET overheating, explosion
imminent"), you're still faced with: [A] Human reaction time (controller
and pilot); [B] taking the necessary immediate action (split the
SRBs from the ET and/or split the orbiter away from the ET); and
[C] surviving (getting far enough away from the ET before it goes
*BLOOIE*, and then completing a very difficult dead-stick turnaround
and landing, or a tough water ditching). In the case of the Challenger
explosion, it looks as if all three of these factors were dead-set
against the crew... there was very little time to react, no way
to get away, and a water ditching would probably have killed many
of the crew.
I imagine that you could certainly build an expert system that would
be capable of reading the shuttle's telemetry, and warning of most
conditions THAT THE DESIGNERS OF THE SYSTEM HAD TAKEN INTO ACCOUNT!
The real problem lie, of course, in detecting conditions that no one
had expected would occur... if the system has no rules that would lead
to a conclusion such as "The SRB segment ring seals are leaking",
then the system will never report such a condition. At best, some other
warning will be reported ("Asymmetric thrust from SRBs exceeding
2%"); at worst, no warning will be received, or the system will issue
warnings unnecessarily ("Heavy engine vibration").
I don't think the worries about plutonium should be dismissed out of hand. It is my understanding that the lethality of plutonium is due to its extreme toxicity, as opposed to its radioactivity. Comments from a knowledgeable chemist are eagerly solicited.
I took the liberty of forwarding Gary Leaven's question on earthquake
monitoring systems (ie, are they designed to function during a major
earthquake?) to Mike Raugh, the author of the CACM article which
prompted the question. Here's his reply:
---------------------------------
Matt,
The question you forwarded to me is a good one: Are the
seismic instruments used in Calnet and the Southern California Array
built to withstand the shaking of a major earthquake? The answer is
Yes and No, but it doesn't matter! Even if a local subset of
instruments (or the telemetry system serving that subset) is
knocked out by a major quake, more distant instruments will pick up
signals from the quake that will be adequate for locating, timing and
calculating the earthquake "mechanism", i.e. direction of first motion,
plane of rupture, magnitude. The purpose of the two arrays is to
monitor earthquake activity throughout California, so you can see that
the entire combined two arrays will almost certainly not be totally
incapacited by a major quake, hence they will continue to monitor
activity (even distant activity) successfully.
That being said, it should also be mentioned that seismologists
are very interested in the fine-grained signals that are obtainable
only at close range to a major earthquake (seismic waves that have
traveled teleseismic distance through the earth lose much of the higher
frequency energy). Such close-in data from large earthquakes can only
be obtained from special "strong motion" instruments: this type of
instrument furnished the data for Archuleta's study of the Imperial
Valley quake discussed in my paper. Strong motion instruments are much
more difficult to make, for all the obvious reasons, and are
expensive compared to the ones that comprise the two arrays mentioned
above.
The problem of designing sophisticated modern microcomputer
based instruments that have sufficient sensitivity and dynamic range
and are robust in the presence of violent shaking is a big one.
Especially when you consider that such instruments must have local
storage and power supplies to back up data collection in the event of
telemetry break-downs. I can think of two groups at the USGS in Menlo
Park that are working on systems of this kind. The first is lead by Roger
Borchardt (his GEOS project was mentioned in my article). Another is
being conducted by Larry Baker, Joe Fletcher, and Paul Spudich, who are
developing a down-hole three-dimensional mesh of instruments for
observation of the detailed progression of faulting expected to occur
in the officially USGS-predicted earthquake at Parkfield. In other
words, new designs for such instruments are on the frontier of research
and development at the USGS. Very likely other work of similar import
is taking place elsewhere.
I hope this answers your question.
Mike
Neither of these stories involves mainline computer risks, but they might contribute some insight. I got this story from a friend doing earthquake research for the USGS. I think it was '71 when a bigish quake near LA collapsed a VA hospital and a half constructed bridge. That generated a lot of interest in the way buildings (and bridges) react to quakes. Nobody really knew how much stress is present on various structural parts of a building. In response, many strain recording gizmos were installed in many large buildings. Time passed, and everybody went back to their normal work. After several years, another bigish quake came along, and somebody remembered all those installed instruments. So they went out to collected them. Most of them had died. I don't remember any numbers, but I was left with the feeling that everybody was discouraged that they didn't get much interesting data. Another friend worked on LASA (Large Area Seismic Array?). It was one of the early seismic arrays with hundreds of sensors scattered over eastern Montana. I think it was primarily part of the bomb test detection program. With that many sensors and that much wire and electronics to collect all the data, a few sensors were always off the air. They discovered that they got better data if they didn't tell the fixit crew that a test was coming.
... I can tell you that earthquake instrumentation really need not survive a local earthquake. Local measurement is very unreliable because of environmental factors: soil type, underlying geologic structures, and so forthPlease report problems with the web pages to the maintainer
xTop