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…
I mentioned the F-16 RISKS contributions to my Software Engineering class yesterday. After class, one of the students told me the following story about the B-1 Flight Simulator. The student had been employed over the summer to work on that project, thus having first-hand knowledge of the incident. Seems when a pilot attempts to loop the B-1 Flight Simulator that the (simulated) sky disappears. Why? Well, the simulated aircraft pitch angle was translated by the software into a visual image by taking the trigonometric tangent somewhere in the code. With the simulated aircraft on its nose, the angle is 90 degrees and the tangent routine just couldn't manage the infinities involved. As I understand the story, the monitors projecting the window view went blank. Ah, me. The B-1 is the first aircraft with the capability to loop? Nope, its been done for about 70 years now... The B-1 Flight Simulator is the first flight simulator with the capability to allow loops? Nope, seems to me I've played with a commercially available Apple IIe program in which a capable player could loop the simulated Cessna 180. $$ to donuts that military flight simulators with all functionality in software have been allowing simulated loops for many years now. Dick Hamming said something to the effect that while physicists stand on one another's shoulders, computer scientists stand on one another's toes. At least on the toes is better than this failure to do as well as a game program... Maybe software engineers dig one another's graves? And this company wants to research Starwars software... Jus' beam me up, Scotty, there's no intelligent life here.
Equipment failures and human errors are common enough in any human endeavor;
the question is not whether they happen, but whether they present actual or
potential risks of serious consequences. In this context the lack of
publicity is not at all surprising: one form of serious consequence is public
hysteria over insignificant trivia. When an attempt to reach a vacationing
brewery programmer gets blown up into stories of a total production shutdown
and impending beer shortage — this, mind you, in an industry which is *not*
the focus of hostile propaganda campaigns and widespread irrational fears --
the people involved with nuclear plants have every reason to be very quiet
about even routine, unexciting, non-hazardous problems.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
<> From: Nancy Leveson
Acts of God vs. Acts of Man, Round n+1 (eastbound)
Nancy Leveson <nancy@ICSD.UCI.EDU> 30 Aug 86 23:30:36 PDT (Sat)>From Herb Lin: >But the number of assumptions that >designers must make is enormously large, and it is essentially >impossible to even articulate ALL of one's assumptions. Agreed. But there are ways to determine which are the critical assumptions with regard to particular hazards. This is exactly what some of my techniques, e.g. software fault tree analysis, attempt to do. In the Firewheel example that I published, we determined a critical assumption which could have resulted in the satellite being destroyed. That is, if there were two sun pulses detected within 64 milliseconds of each other, the microprocessor interrupt system became hung which could possibly result in destruction of the sensor booms (and thus the usefulness of the satellite). We found this assumption by working backward through the software from the hazardous condition. The solution, once the critical assumption had been determined, was a simple blocking of the second sun pulse interrupt. I don't know for what size systems these backward analysis approaches are practical. It took Peter Harvey (my student) two days to analyze the Firewheel software (which is about 1600 lines long) by hand. Obviously, it would be possible to analyze larger software, but we do not yet know how much this will scale up practically. We are working on a software tool to automate as much as possible. These techniques are, of course, no more perfect than other more traditional software engineering techniques. And better ones may be found. I am just not ready to say it is impossible without first trying. Backwards analysis, verification of safety, software interlocks, software fault tolerance, fail-safe design, ... — there are possible solutions which we should be examining. Nancy Leveson
Computer Literacy
Mike McLaughlin <mikemcl@nrl-csr> Mon, 1 Sep 86 11:49:10 edtFrom THE WASHINGTON POST, Monday, 1 Sept 86, page A14, Letters to the Editor [ "..." indicates omissions]. While I do not entirely agree with Mr. Jordan, much of what he says is directly applicable to Risks. [Before responding to this, please recall that this topic has already been discussed at some length in RISKS-2.36 and 37, and in RISKS-3.17, 19, 20, and 21. PGN] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ COMPUTER LITERACY Although I earn my living as a consultant in computerized data bases, I strongly oppose the view... that computer literacy should be mandatory in the secondary school curriculum. Computers are a device for performing some task that either is already performed by other means or first must be understood in other terms, usually a mathematical equation. Learning how to operate a computer, or program one, is not going to improve a student's knowledge of languages, mathematics, history or political science. Alfred North Whitehead observed that civilization increases the number of things that we can do without thinking, i.e., that we can take for granted. This is evident in the development of computers, which increasingly are becoming like automobiles; anyone can drive them. Learning the technology of computers has as much relevance to everyday life as learning the technology of auto engines. Unquestionably there are tasks for which computers are indespensable, but individuals will learn those functions as they become involved in the task itself, whether it be medical diagnosis, controlling the flow of electric power over a grid or determining the authorship of a 16th-century poem. What students need to know is how to think, especially about the human condition. As more and more college students flock to "practical" majors, the secondary schools should be concentrating on the liberal arts. In this perspective, "computer literacy" may be just another form of a larger illiteracy. - John S. Jordan, Washington, D.C.
Another supermarket crash
<TMPLee@DOCKMASTER.ARPA> Sat, 30 Aug 86 23:26 EDTSame thing happened here (Minneapolis-St.Paul) a couple of years ago — I was in a major discount store (Target), during a normal busy time -- Saturday morning, I think — only to find that all the cash registers wre down because the central computer was down. Don't know how long it lasted, but at least long enough that by the time I got there the cashiers were using paper and pencil. Really, stupid — (so he says as a so-called computer expert) — given that those registers probably had Z80's or 6502 or such in them, a printed record, etc., so they could just as well have worked off-line (except for not knowing the price on instant sale items, which would I assume have been in the central machine.)
A supermarket does not grind to a halt
Brint Cooper <abc@BRL.ARPA> Mon, 1 Sep 86 13:29:45 EDTLast month, as I awaited checkout in a "Giant" supermarket in Bel Air, MD, an area-wide power outage lasting several minutes occured. The following was the sequence of events: 1. All lights, outside and inside, instantly out. 1A. Display on cash register_cum_terminal RETAINED display! 2. Some of the same lights came back almost immediately (seemed to be back-up power). 3. Several minutes passed; additional lights began to come on. 4. One-by-one, the terminals "beeped" and became functional. No market employee with whom I spoke seemed to understand what actually happened. But the computer system obviously was protected from such random power outages (which occur FREQUENTLY here). Brint Cooper UUCP: ...{seismo,unc,decvax,cbosgd}!brl-smoke!abcPlease report problems with the web pages to the maintainer
xTop