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…
[It is never too early for April to roll around. PGN] "This Message Can Not Be Considered Spam, Even Though It Is. Some Law That Never Was Enacted Says So." Dell, Unisys and Microsoft have joined together to produce: DUMvoting 1.0! DUMvoting 1.0 is a simple 375k zipped download which you can install on your machine tonight, and vote for President tomorrow! Worried about hanging chad? Not with DUMvoting 1.0! No, your vote will travel over HEALTHY SAFE Internet connections to our new DUMvoteCenter, located in my next-door neighbor's basement where a 16-year-old computer genius known as SWORDGANDALF will convert it into paper ballots in between Dungeons and Dragons games. (Note: During installation, a pop-up box may notify you that Back Orifice is being installed. This is normal. For best results, please disable all anti-virus software before installing DUMvoting 1.0) NEVER AGAIN will you walk to a voting booth in the rain. NEVER AGAIN will you have to associate with the kind of people (and you know what I'm talking about, I don't have to spell it out for you, do I?) who hang around the voting area. NO MORE messy contact with neighbors. We have got it ALL WORKED OUT for you. And with our new SPEEDYEXITPOLL (c), you won't have to wait till midnight for the outcome! We will be sending our projections the day before the elections, and our exit polls by 11:30 am on election day, saving you both time and anxiety. You must act fast, but DUMvoting 1.0 can be rushed to you for the low, low price of $299.00 from our website at DUMvoting.com. In addition, we will send you OILMAN 3.2, the exciting new game from Microsoft: Alaska's Up For Grabs, And You Have Just Been Appointed To The EPA! Plunder as you will, but watch out for the charging caribou; we're told they have a "thing" for the pipeline! Order without delay. Please include your Social Security number and any recent medical bills. *Sent by the Dell/Unisys/Microsoft Consortium: "DUMideas Last Forever." [Note that DUM spelled backwards is MUD. Must be symbolic. PGN]
The effort to install a new ground radar system for collision avoidance has been set back by the appearance of phantom planes. In earlier tests, a Fremont-based component created ghost images for six nonexistent planes, giving the appearance that two planes were heading for the same runway. The bug has finally been identified (according to a radio report), but it must now be fixed, whereupon tests will continue. [Source: Wire services, 8-9 Jan 2000]
Reuters noted that a Slovenian Adria Airways airplane made an emergency
landing in Ljubljana on 9 Jan 2001 because of a cell phone in the baggage
hold had been left on. It is asserted that the ringing phone corrupted
plane avionics and triggered a fire indicator. [PGN-ed from
http://www.theregister.co.uk/content/5/15995.html]
I'm not certain how this should be classified:
Remarkable detection of RFI without instrumentation?
Remarkable instance of RFI?
Remarkable instance of attributing flight instrument irregularities
to RFI after an aborted flight?
Rhetorical: If this had occurred in the US, would the incident have
counted against the airline's on-time statistics?
Dave Kennedy CISSP Director of Research Services TruSecure Corp.
http://www.trusecure.com
[Also noted by Aydin Edguer at
http://dailynews.yahoo.com/h/nm/20010110/od/aircraft_dc_1.html
PGN
My testimony before the United States Civil Rights Commission hearing on allegations of election-day irregularities in Florida, Jan 11 2001, is indexed on the Web at http://www.cs.uiowa.edu/~jones/voting/uscrc.html My testimony was presented as part of the Expert Panel on Voting Technology, along with testimony from Kimball Brace (Election Data Services) and John Ahmann (Election Supplies Inc, the major Votomatic vendor). My testimony and Brace's testimony were in strong agreement on key issues involving information that must be reported in the canvass of an election that is very irregularly reported today. I made strong statements about the risks of standardizing election technology, as opposed to setting performance standards, and I pointed out major problems with the current regulation of computer software used in elections. It was covered live on CSPAN, and if the USCRC follows its usual procedure, multimedia transcripts of the oral testimony (audio and video) will be on their web site in about a month. Doug Jones <jones@cs.uiowa.edu>
"Hemos," in an article in Slashdot, called my attention to http://www.cnn.com/2001/US/01/12/airborne.laser/index.html This describes a weapons system under development, in which a Boeing 747 will carry an airborne laser capable of shooting down missiles. According to the article: No trigger man No human finger will actually pull a trigger. Onboard computers will decide when to fire the beam. Machinery will be programmed to fire because human beings may not be fast enough to determine whether a situation warrants the laser's use, said Col. Lynn Wills of U.S. Air Force Air Combat Command, who is to oversee the battle management suite. The nose-cone turret is still under construction "This all has to happen much too fast," Wills said. "We will give the computer its rules of engagement before the mission, and it will have orders to fire when the conditions call for it." The laser has about only an 18-second "kill window" in which to lock on and destroy a rising missile, said Wills. "We not only have to be fast, we have to be very careful about where we shoot," said Wills, who noted that the firing system will have a manual override. "The last thing we want to do is lase an F-22 (fighter jet)." "I should've done better, didn't mean to be unkind. Y'know that was the last thing on my mind..." Daniel P. B. Smith <dpbsmith@world.std.com>
On the day before Christmas Eve, usually the day with the highest turnover of the year in all shops, the whole Swiss debit-card (EC-Card) processing system of Telekurs broke down for more than two hours. Also getting Money from ATM's and the processing of on-line MasterCard credit card payments, which is handled by the same company, was interrupted. In Switzerland the debit card "EC card" is quite popular and nearly everyone with an bank account has one of these and also most people use it more or less often. With the EC card, you can get money on ATM's and pay your goods in shops and restaurant by swiping the card and entering your PIN code (no, I don't go into that) like an credit card but the amount is deducted directly and immediately from your bank account. Now on Saturday 23 Dec 2000 at 13:15, a tape robot in an automated tape library in the data center of Telekurs, the sole operator of all EC card transactions, drops a tape on the floor which in turn leads to an error propagation which shuts down the whole EC and MasterCard card processing for approximately two and a half hours until 15:25. The impact was quite unpleasant: thousands of frustrated people unable to pay the Christmas presents for their loved, high revenue losses for the shops on the most important day of the year and more than 100,000 transactions rejected. What do we learn from this? The usual story: don't put all your eggs in the same basket; have better failure recovery procedures in place for such an important system, it should not be possible that a dropped tape brings the processing of all transactions to a grinding halt. For reference coverage by the media (in German): http://archiv.nzz.ch/books/nzzmonat/0/$72NB6$T.html Andre Oppermann
O'Connor (Risks 21.18) and Payne (Risks 21.19) have recently discussed the 1994 RAF Chinook transport helicopter crash on the Mull of Kintyre. And then there is Ryan O'Connell's contribution, of which more later. This is a very public discussion in the UK. It is said to be the first time that the Royal Air Force has put an accident report in the public domain (J.M. Ramsden, "RAF Safety after Chinook", Pilot, November 2000, p22) and the controversy is sufficiently well developed for the UK defence minister at the time of the accident, Sir Malcolm Rifkind, to have requested one of his successors, Geoffrey Hoon, to set aside the finding of gross negligence reached by Sir William Wratten (op. cit., p23). It is probably the first time ever that an Air Chief Marshall with authority to determine an accident finding has written an article in the "popular" aviation press to explain his finding (Air Chief Marshall Sir William Wratten, "Why those Chinook pilots were `grossly negligent'", Pilot, August 2000, pp20-21). Here is a brief description of the controversy. The Kintyre peninsula is long, narrow, hilly (one hesitates to say "mountainous") piece of Scotland whose end, the Mull of Kintyre, attains a height of 1404ft MSL (above mean sea level) and is some 20km (13 miles) or so across the North Channel from the nearest point of Northern Ireland. There is a lighthouse on the west side of the Mull, directly below the "peak" (Ordnance Survey, Routemaster Series, Number 3, Western and Central Scotland, ISBN 0-319-23003-1). The flight was performed under a Visual Flight Rules (VFR) flight plan. Visual flight was performed over the North Channel. Close to the lighthouse on the Mull, the aircraft flew into Instrument Meteorological Conditions (IMC) and hit ground at 810 feet, some 2,000ft below Instrument Flight Rules (IFR) Safety Altitude for this sector of the planned route, calculated to be some 2,800ft MSL, at a groundspeed calculated by the Air Accident Investigation Branch to be some 150kts (Wratten, op. cit., p20. 1 knot (kt) is 1 nautical mile (nm) per hour; 1 nautical mile is about 1.15 statute miles). The aircraft was equipped with a "SuperTans" GPS-based navigation computer (Ramsden, op. cit., p21), and a VFR flight plan waypoint change was made, to a waypoint some 87nm beyond the lighthouse, less than one nm from what was to be the point of impact (Wratten, op. cit., p20). The accident flight was equipped with neither a flight data recorder nor a cockpit voice recorder. All parties to the controversy agree that we can never know exactly what happened or why. We want to know why those highly trained and experienced pilots flew into IMC on a VFR flight plan, and why they did not perform regulation and trained maneuvers for such an eventuality (slow down, climb immediately to at of above IFR Safety Altitude for that sector, and immediately initiate a turn away or a 180-degree reversal of course out of the IMC and back into the Visual Meteorological Conditions (VMC) from whence you have just come. Wratten, op. cit., p20). We shall never know the answers to these questions. Flying into IMC while under VFR is one of the biggest killers of general aviation pilots and their passengers. It also kills lots of professional "bush" pilots in places such as Alaska. Every pilot, *every pilot*, including students, is explicitly trained both to avoid doing that, and in what to do if you do it anyway (namely, the maneuvers described above, which are universal). The Chinook helicopter, known as an HC.2 in UK military service, is a twin-rotor heavy transport helicopter. It has one rotor fore, just behind and over the cockpit, and one rotor full aft of the long fuselage. The HC.2 has a history of engine control system malfunctions (it is equipped with Full Authority Digital Engine Control, FADEC), including uncommanded "run-ups" (Ramsden, op. cit., p21). I take this to mean either an uncommanded increase in power output or an uncommanded increase in rotor RPM or both, but I don't know the exact history. Ramsden refers to Squadron Leader Bob Burke, an RAF Chinook test pilot who has experienced "uncommanded HC.2 rotor runaways" (op. cit., p23). Furthermore, on the day of the accident flight, one of the flight crew asked groundcrew to check the navigation computer for "unusual GPS satellite tracking data. This check was completed with `no fault found'" (Ramsden, op.cit., p21). RAF Rule AP.3207.8.9 requires that there be no doubt in the case of a finding of pilot negligence (Ramsden, op.cit., p21). The controversy is briefly as follows. ACM Sir William Wratten asserts that there is no doubt that the pilots flew into IMC conditions on a VFR flight plan, and that there is no evidence of any technical malfunction which could have caused them, against their training, to do so. His most reasonable critics believe that there is indeed such doubt: for example, an uncommanded run-up of the sort previously seen on the HC.2 could have caused the flight pattern out of VMC into IMC and impact with the Mull (for example, Ramsden, op. cit., p23, cites specific critics and an article in Pilot, October 1999, which I have not read). Sir William replies that there is incontrovertible evidence that the decisions and action of the pilots that led to flight into IMC occurred independently of the occurrence of any such technical problem or other factors presumed by some critics to be relevant (Wratten, op.cit., p21). Much of the debate centers on the nature of RAF accident investigation procedures, the nature of doubt and what kinds of considerations and evidence lead to it (the nature of hypothesis, plausibility, and their place in accident reports), the nature of justification and sufficient justification under conditions of uncertainty, the purpose of accident reports according to the RAF and whether the RAF's finding in this case fulfills that purpose, whether there is a "culture of blame" in RAF incident investigations, whether certain kinds of potential evidence was ignored, and whether it should have been, and the effects of the finding on military personnel as well as bereaved families, as well as the nature and role of secrecy and openness in accident investigations. I believe that civil societies need to consider such issues, and it is clear that the RAF investigators and their commanding officers, as well as their more reasonable critics, are acting in good faith and the controversy is intellectually serious. I believe the debate is socially healthy. But then I would, wouldn't I, given my interests in the analysis of complex system failures? Well, not inevitably. I contrast the Chinook debate with that over the 1988 Airbus A320 accident at Habsheim, on which debate I have expressed my views, based on a first-level Why-Because Analysis, elsewhere (Section 5 of "Causal Reasoning About Aircraft Accidents, pp 344-355 of Computer Safety, Reliability and Security, Proceedings of the 19th International Conference, SAFECOMP 2000, ed. Koornneef and van der Meulen, Lecture Notes in Computer Science, Volume 1943, Springer-Verlag, Berlin, Heidelberg, New York, 2000). Back to the RISKS contributions. O'Connell (Risks 21.19) seems to believe that the distinction between VFR and IFR doesn't exist for the UK military, that the pilots "would have" been operating under some other unspecified flight rules than VFR or IFR, that they were using terrain-following radar, and that it is OK to perform terrain-following flight in IMC in the vicinity of steeply-rising terrain, and that they might well have been doing that because they were worried about anti-aircraft fire from terrorists. Whereas O'Connor's and Payne's intellectual VFR has kept them and RISKS readers well clear of clouds, O'Connell is flying, thankfully solo, into IMC. Lighthouse keeper PGN, observing right on the border between VMC and IMC, failed to notice despite his sense of smell that O'Connell was flying directly into the Mull. It remains for our moderator only to explain the pun. Peter Ladkin
The current debate about the June 2nd 1994, RAF Chinook Flight ZD 576 crash
into the Mull of Kintyre centers on the Full Authority Digital Engine
Controller (FADEC) used by that helicopter. The FADEC was built by the
Textron company.
In Risks 21:18 John O'Connor makes a case for Controlled Flight
Into Terrain due to pilot error compounded by weather factors.
In Risks 21:19 Phil Payne makes a case that an additional risk was
not having a recording of the flight data.
Also in Risks 21:19 Ryan O'Connell makes a case that a risk mitigator for
low level flight in fog is the on-board terrain following radar and the
military pilots training for "Nap of Earth" flying. My understanding is
that even with radar, "Nap of Earth" flying is a high workload activity.
A search of the United States' National Transportation Board's (NTSB)
Aviation
page:
http://www.ntsb.gov/Aviation/Aviation.htm
found three FADEC related helicopter crashes, and also the fact that the
FADEC itself permanently records some flight data.
The accidents are:
(1) FTW96LA395; September 21, 1996, a Bell 407 helicopter; registration:
N1114S
(2) MIA97RA005; OCT-09-96; a Bell 407 helicopter; registration: N1117P
(3) FTW97RA055; NOV-20-96, a Bell 407; registration: ECGJC
Note the closeness of the dates and two of the registrations.
All of these crashes were considered pilot error. Readers of this forum may
recognize a human factors risk in the interface and procedures for recovery
from FADEC failure. From the FTW96LA395 accident report:
"According to the Bell 407 Rotorcraft Flight Manual, when the FADEC FAIL
warning light illuminates in flight, the pilot should accomplish the FADEC
FAILURE procedure as prescribed in paragraph 3-3-K. The procedure is,
immediately retard the throttle and hold it to the 90% throttle bezel
position; maintain Nr (rotor) with collective only; depress the FADEC MODE
switch one time regardless of switch indication, FADEC will switch to MANUAL
mode 2 to 7 seconds after this action if it is not already in manual mode;
maintain Nr 95% to 100% with throttle and collective; land as soon as
possible, and perform a normal shutdown if possible. There is a warning that
2 to 7 seconds after the FADEC FAIL warnings, FADEC may be in MANUAL mode
without any pilot action. Nr may increase very rapidly and overspeed to
110% which will result in an engine flameout unless the pilot takes
immediate manual control of the FADEC with the throttle."
The fact that FADECs have a permanent record of their data comes from the
Statement of Mike Poole to the Transportation Safety Board of Canada
speaking about the September 2nd, 1998, SwissAir MD-11 crash off Peggy's
Cove: "the FADEC from the Number 2 engine gave us data in those last six
minutes of the flight where the recorders had already stopped. So, in this
case, the non-volatile memory was extremely useful."
http://www.ntsb.gov/events/symp%5Frec/proceedings/may%5F3/sessioni/poole%5Ftranscript.htm
The procedure for recovering from failure, the risk of engine failure if the
procedure is not followed and the existence of non-volatile memory in the
Textron FADEC are confirmed by the Bell Helicopter/Textron website:
http://32.97.252.12/print/encyclopedia/407pdb/section1/page_1_123.html
A probable cause for the June 2nd 1994, RAF Chinook Flight ZD 576 crash into
the Mull of Kintyre may include a human factors risk in the interface and
procedures for recovery from FADEC failure. This would be aggravated by a
high workload flight regime. Data for whether or not there was a FADEC
failure should have been available in the non-volatile memory built into the
FADEC.
Mike Beims <mbeims@ivv.nasa.gov>
In my opinion, the armchair analysis of the Chinook crash by RISKS participants is a pointless exercise. The military does not operate in a risk-free environment. They regularly take on risks which would be unacceptable to the general public. This does not imply that they should be absolved in cases of recklessness, but the tone of the discussions so far seems to be alarmist. For a bunch of computer jocks to try to tell the military its business when it comes to operations is the height of arrogance. For a picture of the types of risks involved in military helo ops, read the book "Black Hawk Down" by Mark Bowden. Not having served in the military myself, I cannot attest to its accuracy, but it was well received by soldiers involved in the actions described. Some of the book also appears with supplementary material on the Philadelphia Enquirer web site: http://www.philly.com/packages/somalia/ Nathan Pemberton <nathanp@ix.netcom.com>
Re: Chinook (O'Connell, RISKS-21.19) The Officer in Charge has been held responsible, he/she died in the crash. Given that the Board of Inquiry does not indicate that the aircraft was under ground control, I presume that someone on board, likely the pilot, was the Officer in Charge, and made the decisions that lead to the crash. A Military Board of Inquiry is made up of both peers and superiors of the Officer in Charge. The function of the Board is to examine all the factors leading to an incident, and to examine whether the Officer in Charge made correct or reasonable decisions along the way. In this case the Board has evidence that decisions made and risks taken were NOT appropriate for the threat environment. The Captain usually goes down with his ship, whether he/she lives or dies is a separate matter. The risk is we overlook a potential cause for future problems, because this ruling implies that the aircraft operated flawlessly. In this case the "cause" of the accident is clear, but we may still need to examine why the aircraft intersected the ground. If for no other reason than to make future Nape-Of-The-Earth operation as safe as it can be...
In Multnomah County, Oregon, about 3000 residents have been summoned to show up for jury duty in 1901. One person responded that he couldn't possibly get there in time because he had not yet been born. [Source: Michelle Roberts, *The Oregonian*, 3 Jan 2001; PGN-ed]
I received one of those countdown to the millennium clocks for Christmas 1999. It counted down the days/hours/minutes/seconds to Jan 1, 2000. When it reached zero, the displayed stayed at all zeros and flashed. Everything worked great. It has a mode function that you can get it to count down to Jan 1, 2001 (they call this scientific mode as opposed to celebration mode). After New Years 2000, I set it to scientific mode and forgot about it. A couple of days before New Years 2001, I dug the clock out and noticed that the count down was off by a day. It was displaying 1 day and several hours to new years on Dec. 29th. I figured that it had lost a day sitting in my drawer. When I checked the actual day (you can set it to be just a date/time clock as well), it was correctly set to Dec. 29th. It turns out that the date/time software/firmware correctly dealt with leap year 2000, but the countdown code missed the boat. It must have been hard coded to count down to Jan 1, 2000, and then they probably added 365 days for the count down to 2001. My Millennium clock has a millennium bug. Mike Palmer
Doesn't the problem of 54 weeks in a year depend on how week numbers are calculated? The problem of 54 weeks seems to depend on starting weeks on a Sunday and counting Week 1 as being the week containing 1st January. Hence in the case of 2000 you get a Saturday fragment in Week 1, 52 Weeks running Su-Sa, and a Sunday fragment in Week 54. The web page http://www.year2000.com/y2kcurrent1.html appears to make these assumptions. The ISO standard for dates and times (ISO 8601) works differently by starting weeks on a Monday (that's not the important bit) and making Week 1 of a year the week containing the first Thursday. Hence week 1 of 2000 began on 2000-01-03 and the preceding Saturday and Sunday belonged to Week 52 of 1999. I've tried to find year that has 54 weeks using the ISO definition, but failed. The standard is at http://www.iso.ch/markete/8601.pdf and there are useful links from http://www.egroups.com/group/iso8601 I think that this standard becomes ever more important now that we're in the low year numbers of the century. We'll look back on dates like 03/05/02 and wonder what on earth it means, given the YY/MM/DD, DD/MM/YY, MM/DD/YY (and other) possible interpretations. I hope this doesn't prove to be a week argument and that people will be encouraged to make a date with a standard. 'o-Dzin Tridral, Senior Computer Officer, UIS, Cardiff University, PO Box 78 CF10 3XL +44 29 2087 6160 TridralO@cf.ac.uk W http://www.cf.ac.uk
PGN wrote: The year 2000 began on a Saturday and ended on a Sunday; ergo, 54 calendar weeks. It is highly unlikely that week numbering was part of the cause [of the Norwegian anomaly]. Norway and the rest of Europe adheres to a different definition of the week than the US, where the week starts on Monday. There is also an ISO spec that defines week numbering. That spec states that week 1 of a year is the first week that has at least 4 days in that year. So if the year starts on a Friday, Saturday or Sunday, those first days still belong to the last week of the year before. If we look at 2000, the first two days are week 52 (they are part of the last week of 1999) and 31 December is exactly the last day of week 52 of the year. Paul van Keep [But some people use U.S. calendar software written by non ISO-aware folks! PGN]
Please report problems with the web pages to the maintainer