[This is a remailing of a hitherto undelivered 10 April posting from Brian Randell, Computing Laboratory, University of Newcastle upon Tyne.] BOEING 737 PROBLEMS REACH FRESH HEIGHTS by John Kavanagh, Computer Weekly, 6 April 1989 Autopilot computer systems on Boeing 737s have been hit by a problem which has caused aircraft to change height without warning. It is believed that full details of the problem have been requested by the investigators into the crash of the British Midland 737 on the M1 motorway in January. One theory is that the crew were misled by cockpit instruments. Six incidents have been recorded by British Airways on its aircraft but the company says there has never been any danger because the crews have always checked the autopilot actions against other cockpit instruments. Boeing and Honeywell Avionics, manufacturer of the autopilot system, have alerted airlines using the 540-plus aircraft affected. "We have been working with the airlines and the regulatory autthorities to fix the problem." Boeing says. The problem occurs after a pilot enters a new height to the autopilot. The system displays the instruction, but under certain circumstances the aircraft moves to a different height and the autopilot then displays the new reading. One senior British Airways captain says the autopilot seems to use instructions entered earlier, even as long ago as the previous flight. British Airways has called the problem "random memory initiation" and says it is caused by unexpected electromagnetic conditions such as lightning, strong radar signals, or an electrical power surge. Boeing says it has no evidence of any accidents occurring because of the problems.
Cockpit Computers Defy Pilots By David Learmount, Air Transport Editor (From Flight International, 4/8/89) Airliners have levelled out at incorrect flight levels as a result of flight management computers overriding pilot instructions. This results from a phenomenon which British Airways has named random memory initialisation (RMI). BA says that modifications it has carried out have eliminated the problem. A line pilot has described RMI as "an increasingly common defect," although replacement of the microchips thought to be responsible is being carried out. The faults are most common, according to aircrew, in the early part ofa flight after the aircraft has been on the ground for some time. BA has experienced problems on all of its aircraft types fitted with electronic flight management systems. The theory is that chips are retaining instructions which should have been overridden by the pilots' latest entry into the flight management system. The earlier instructions sometimes override the current ones, changing not only aircraft performance, but the digital display showing the effective instruction. If the pilots are monitoring their flight management control display, they should see the change take place, or the incorrect entry come up. In busy phases of flight, however, such events have been missed. A change in selected parameter has been known to tkae place in the 737-300. In the glass-cockpit 757 and 767, the more likely error is that the aircraft may fly through the set "height-acquire" flight level, or depart from the one it is at, although the value in the "height-acquire" window remains as selected. The latter two events are likely to be discovered quickly beacuse the crew will be monitoring flight level. An airline pilot tells FLIGHT that some aircrew believe this sort of event may be contributing to pilots' scepticism about information displayed in modern cockpits--a human factor under investigation in the British Midlands 737 accident. Pilots may enter one set of of information, then act on different data which is displayed. In one incident, a BA 737-300 on airtest out of Heathrow was cleared to descend to flight level 80 [8,000 feet]. The crew believe they entered FL80 in height-acquire, and saw it on the mode control display. The aircraft levelled at FL70, and air traffic control queried the action. The crew saw that FL70 was entered on the "height acquire" window of the flight management mode control panel and queried the ATC instruction. The pilot then set FL80 on "height-acquire" and climbed to it. The crew then flew level for a short time at FL80 and, while watching, saw the height-acquire display change to FL70. Another 737-300 pilot has remarked to FLIGHT that, while dialling the height-acquire instruction, care is necessary because the display can settle one flight level above or below the figure entered. BA admits to changes of these types occurring a recorded six times for a reason classified as "transient electromagnetic condition" (TMC), which they say has now been cleared by modification. TMC can be induced by current surges, and it is a well-known electronic phenomenon. Power surges or other forms of TMC can occur under well-recognised conditions, such as changeover from ground power supply to aircraft generators, lightning strikes, and radar proximity. Effects have also occurred when the cause was not obvious. It is not clear whether BA references to events resulting from TMC are the same--or related to--pilot reports of RMI detailed in BA's monthly Air Safety Review. TMC problems have been dealt with by changes to software, hardware, and the mode select panel. BA says that there have been no further reports of problems since the modifications were made. -------- An observation: Modern glass cockpits (i.e., not the 757, 767, or A310) all use tape altimeters. Reading errors are common on such displays. In addition, these displays are not standardised; some scroll down to indicate increasing altitude; some scroll up. Some have a "highlight" window, showing current digital altitude; some don't. Setting errors, combined with read errors, could be fatal. Media observation: pilots are being increasingly portrayed as "reactionary old fogies whose fears might actually be justified"--as if the manufacturers and the industry, in general, are the bearers of Light and Goodness. :-) Robert Dorsett Internet: email@example.com UUCP: ...cs.utexas.edu!walt.cc.utexas.edu!mentat
Many of the recent postings seem to have a lot in common. They all deal with some form of technological defect. Airbus accidents blamed on faulty computers, Audi 5000's effected by radio interferance, Elevators in which Micro processors fail to detect open or blocked doors, fire control systems which mis-identify civilian planes, the list goes on. Each of the incidents above have, of course, another thing in common, they were designed by humans. What are the risks associated with technology we don't properly understand? As we have modernized elevators, planes, cars and fire control systems, they seem to have become not only more complicated but more trouble prone. I am reminded that K(eep) I(t) S(imple) S(tupid) is perhaps something we should reevalute by the NOVA episode "Beyond Top Gun" in which Korean war pilots said, while flying in Vietnam, the first thing they did in a dogfight was start turning things off starting with the back seaters' intercomm followed by some of the warning buzzers and other techno whiz bangs. Ian
One advantage of Winchester-type disc drives is that they are sealed against smoke and other particulates. Hard drives with removable media, however, must have ``absolute'' filters, since smoke particles are larger than the flying height of a typical disc head. It's a fine theory to warn your customers not to smoke, but who's going to check up on third-shift operators? At a famous West Coast computer company where I worked in the early seventies, the newly founded disc division had just shipped their first production drive to the computer division for testing. A friend of mine in Systems Integration believed it was not his duty to coddle the equipment, but to subject it to more typical real-world conditions. He installed the drive, got the diagnostics running on it, and then lit a cigar and proceeded to exhale all the smoke directly into the disc's air intake. SPANG---head crash. The disc division tried to ``blame the messenger'' and wanted my friend fired, but the computer division backed him up. Result: by the time this model went to real customers, it had an absolute filtration system, and eventually proved to be quite reliable.
What do the readers of this forum think are the risks involved in using "Standard" tools such as lex or yacc etc. in developing sensitive applications? Is it reasonable to set some criteriaa for saying that a given tool has withstood the test of time therefore it can be safely used? If so what should this criteria be? Terry Arnold
For those of you interested an umbrella organisation has been established in the UK to co-ordinate information on, and research into, all aspects of computer security. In the first instance one of the organisation's primary concerns will be combatting the threat posed by computer viruses by acting as a clearing house for virus information and control software. Below is a copy of an initial letter mailed to prospective members: The Computer Threat Research Association The computer threat research association, CoTra is a non-profit making organisation that exists to research, analyse, publicise and find solutions for threats to the integrity and reliability of computer systems. The issue that caused the formation of CoTra was the rise of the computer virus. This problem has since become surrounded by fear, uncertainty and doubt. To the average user the computer virus and its implications are a worry of an unknown scale. To a few unfortunates whose systems have become a critical issue. The key advantage of CoTra membership will be access to advice and information. Advice will be provided through publications, an electronic conference (a closed conference for CoTra's members has been created on the Compulink CIX system) as well as other channels such as general postings direct to members when a new virus is discovered. CoTra membership will be available on a student, full or corporate member basis. All software that is held by CoTra that enhances system reliability, such as virus detection and removal software, will be available to all members. It is intended to establish discounts with suppliers of reliability tools and services. A library of virus sources and executables and other dangerous research material will be made available to members who have a demonstrable need. A register of consultants who have specific skills in the systems reliability field will be published by CoTra and reviews of reliability enhancing software will be produced. Your support of CoTra will ensure that you have the earliest and most accurate information about potential threats to your computer systems. CoTra, The computer threat research association, c/o 144 Sheerstock, Haddenham, Bucks. HP17 8EX - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Part of the organisations aims is to establish reciprocal links with other similar organisations worldwide, to facilitate the sharing of experience and rapid flow of information on new threats. To this end if you are involved in (or have contacts with) a similar organisation in your country, please write to CoTra (or by email to me, and I will forward your correspondence) outlining your organisation and its aims. Yours sincerely Dave Ferbrache Personal mail to: Dept of computer science Internet <firstname.lastname@example.org> Heriot-Watt University Janet <email@example.com> 79 Grassmarket UUCP ..!mcvax!hwcs!davidf Edinburgh,UK. EH1 2HJ Tel (UK) 031-225-6465 ext 553
In times of emergency such as this, we suspect that such requests can be [used] legally by appropriate agencies without too much fuss. Part of the problem here is not that the technique was used, but that it was done without judicial approval. The bank *chose* to co-operate, on the word of the police authorities. In this case, the situation was fairly clear. What if it's a foreign student who is accused of being a ``terrorist''? Such accusations by the government have already been thrown out of court on several occasions. (The student may or may not be one; that's irrelevant.) --Steve Bellovin
> Date: Sat, 22 Apr 89 11:35:21 PST > From: David Schachter <david%daisy@sri-unix.UUCP> > Unfortunately, I couldn't get anyone interested in modifying the > WWV/WWVH code to include a public-key encipherment approach, so that > if the clock can decode the signal, the signal must have come from WWV/WWVH. > — David Schachter The signal must have come from WWV/WWVH _at some time_! This would verify the source of the signal, but not the timeliness. Your clocks could be set back by broadcasting a tape of WWV/WWVH. The encipherment only solves half the problem. Don
Please report problems with the web pages to the maintainer