Return-Path: | 'owner-risks@csl.sri.com' |
Received: | from csla.csl.sri.com([192.12.33.2]) (30758 bytes) by inet.sena.gr |
via sendmail with P:esmtp/D:user/T:local | |
(sender: <owner-risks@csl.sri.com>) | |
id <m10vVdT-00001fC@inet.sena.gr> | |
for <dds@senanet.com>; Sun, 20 Jun 1999 03:38:59 +0300 (EEST) | |
(Smail-3.2.0.101 1997-Dec-17 #1 built 1998-Oct-12) | |
Received: | from localhost (daemon@localhost) |
by csla.csl.sri.com (8.9.1/8.9.1) with SMTP id RAA20452; | |
Sat, 19 Jun 1999 17:37:29 -0700 (PDT) | |
Received: | by csla.csl.sri.com (bulk_mailer v1.5); Sat, 19 Jun 1999 16:01:38 -0700 |
Received: | (from server@localhost) |
by csla.csl.sri.com (8.9.1/8.9.1) id QAA19287 | |
for risks-outgoing; Sat, 19 Jun 1999 16:01:37 -0700 (PDT) | |
Received: | from chiron.csl.sri.com (chiron.csl.sri.com [130.107.15.73]) |
by csla.csl.sri.com (8.9.1/8.9.1) with ESMTP id QAA19249 | |
for <risks@csl.sri.com>; Sat, 19 Jun 1999 16:01:23 -0700 (PDT) | |
From: | risks@csl.sri.com |
Received: | (from risko@localhost) |
by chiron.csl.sri.com (8.9.1/8.8.7) id QAA07944; | |
Sat, 19 Jun 1999 16:00:48 -0700 (PDT) | |
Date: | Sat, 19 Jun 1999 16:00:48 -0700 (PDT) |
Message-Id: | <199906192300.QAA07944@chiron.csl.sri.com> |
To: | risks@csl.sri.com |
Newsgroups: | comp.risks |
Subject: | Risks Digest 20.46 |
Sender: | owner-risks@csl.sri.com |
Reply-To: | risks@csl.sri.com |
Status: | U |
Content-Length: | 4292 |
RISKS-LIST: Risks-Forum Digest Saturday 19 June 1999 Volume 20 : Issue 46 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.46.html> and at ftp.sri.com/risks/ . ***** THE ANNUAL SEASONAL SLOWDOWN BEGINS NOW. ***** ***** BIG BACKLOG of incremental stuff not included. *** Contents: NASA discloses space station blunder (SigmaXi ScienceInTheNews) Y2K test sends sewage flowing in Los Angeles (Henry Baker) Resetting the A320 computer (Diomidis Spinellis) Intuit/Quicken Force Users to Internet & MS Internet Explorer (Lauren Weinstein) MS Word not as helpful as it thinks (Bill Shymanski) YANTBOF: yet another NT buffer overrun flaw (Epstein Jeremy) New ATM hazard (Aahz Maruch) Yet another ATM scam (Mike Williams) The cell phone that wouldn't stay OFF (Michael Heilman) Another case of credit-card 'security' (David Alexander) Maldesigned computer system slows background checks (Kragen Sitaker) Factoid paranoia (Mike Giroux) Risks of keywords in CSV files (Rex Black) REVIEW: "Intrusion Detection", Edward G. Amoroso (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- [...] ------------------------------ Date: Sat, 19 Jun 1999 03:05:01 +0300 From: Diomidis Spinellis <dspin@aegean.gr> Subject: Resetting the A320 computer I was travelling from Athens to Munich on Lufthansa flight LH 3425 on 16 Jun 1999. Shortly before taxiing for takeoff, our A320 plane left the runway and moved aside. The captain immediately informed us that we were having a slight technical problem that they would try to rectify and that we would be given further information in a short while. About five minutes later the following announcement was made: "Ladies and Gentlemen this is your captain again. We had to reset two of our computers and now it is looking real fine again." During the flight the crew kindly allowed me to talk to the first officer about the incident. My prepared list of questions concerned the problem domain, its criticality, frequency of occurrence, and reporting procedures. According to the captain, the problem occurred on a flight control computer (ELAC1) and involved erroneous position monitoring of the right elevator. The officer assured me that the problem was not critical, occurred on only one of four different reports and although it was part of a ground checklist it would not have been a problem during the flight. I was told that such problems sometimes do occur and that the problem had already been reported by telex to the airline's maintenance base. Here is a verbatim - I hope - transcription from a printed log I was shown: F/CTL servo fault R Elevator POS MON XDLR (Disclaimer: I am not an aviation expert; the report is my - perhaps limited - understanding of the captain's answers.) The risks? As far as I know modern flight-control computers do not need a reset before takeoff*, nor should a reset be needed after a human operator error. Obviously a software or hardware fault had caused the computers to malfunction. Since resetting a computer does not typically isolate and correct faults (otherwise Windows would long have reached a 0% defect rate), we were flying on a plane with a known and demonstrated software fault. Although the problem manifestation was on a non-critical area, we all know that the underlying cause could well result in more serious side-effects since it occurred on a critical flight control component. More worryingly, this appeared not to be a singular event. [*] Interestingly the Space Shuttle software does need to be reloaded between different flight phases. A fascinating description can be found in Gene D. Carlow. Architecture of the space shuttle primary avionics software system. Communications of the ACM, 27(9):926-936, September 1984. Diomidis Spinellis, University of the Aegean ------------------------------ [...] End of RISKS-FORUM Digest 20.46 ************************