The following is a letter re Flight 261 to an investigative reporter with the Seattle Times. It was posted on Humpty Dumpty Y2K at

http://www.egroups.com/group/humptydumptyy2k/1107.html? 4:31 PM Mon 7 Feb

---------- From: "Roman Mach" Date: Sun, 6 Feb 2000 08:48:57 -0800

Subject: Something to consider about Alaska crash investigation

Hi Byron Acohido:

I got your name from an article you wrote about the tail integrity of Flight 261 and saw you are an investigative reporter.

http://www.seattletimes.com/news/nation-world/html98/plan_20000201.html

Given that, I want to present what I consider some interesting evidence, all circumstantial, about the crash that you may want to pursue, namely that there is a Y2K problem with the MD-80 series. As far as I know, and oddly so, I have not seen anyone yet propose the Y2K theory for this tragedy.

The information I'm going to present is entirely based on conjecture as I have no other information about the crash than what I see in the news reports. I have no prior or current affiliation with Boeing or MD and have never worked on planes. I am also copying Ed Yourdon (Software and Y2K expert) as he may have some insight into what I have to say.

I think there is now enough evidence to make the following claim reasonable. I believe that the crash was a result of a Y2K problem with the plane's digital controller. Before you dismiss me as a scaremonger, I am a software engineer at an Internet firm and I headed up the Y2K efforts of our software systems at Saltmine. In the course of this process I became very adept and spotting potential Y2K problems or causes. I have also worked with hydraulic systems on boats and understand some of the hydraulic/mechanical issues that the plane could have experienced.

Here is the reasoning. You can accept it or reject it, but please give it some consideration:

1. In the words of a Boeing web site:

"Technology advancements in the MD-80 include aviation's first digital flight guidance system."

I don't know if this means that flight control surfaces are always under electronic control (i.e. fly-by-wire) or only when the autopilot is on, but in either case the plane is flown using electronic means at certain times, which means that the plane's control surfaces can change based on computer calculations.

http://www.boeing.com/commercial/md-80-90/index.html

2. The problem occurred with the Alaska Jet within minutes of 4:00pm PST January 31st 2000. So what, you say? Planes are configured to use what I believe is called 'Zulu' time, another term for GMT, or Greenwich time. This is because they need a reference point that stays constant when flying across time zones. It turns out that GMT = PST+8, so 4pm PST is midnight GMT or 0:00 in the plane's computer. Not only that, but in this case it also coincided with the "month rollover": 1/31/00 to 2/1/00.

It is conceivable that a software system on the plane may have been using the current (within seconds) date/time to help in navigation. If the software had a bug when doing a difference calculation between one month and the next then the resulting output could be bogus. Alternatively, someone may have patched specific lines of code in the software that only execute when the month becomes Feb 2000 - this is conceivable given that some programmers originally failed to account for the fact that Feb 2000 is a leap year. This code may never have been tested and may have crashed the software the moment it was input a date in Feb 2000 for the first time. It is also worth noting that most MD-80s were probably grounded during the Jan 2000 rollover, so this problem, if it also existed then, may never have been noticed during the first Y2K rollover event.

So how would a stabilizer jam? Simplifying greatly - A calculation is made in the autopilot that states where the plane should go in terms of heading angle is derived from the direction of flight, current date/time, and current (GPS, beacon or inertial) position. This value is then passed on to setting an angle for the stabilizer so that the plane is always moving towards its destination. If the date/time calculation fails because of a bug when the date reaches Feb 2000 the resulting number output could be anything; it may even be a number so large that when it finally is processed to set an angle for the stabilizer, the angle could be 90 degrees - something the stabilizer cannot reach, but it can certainly try and make it as close to 90 degrees as possible, which would probably be full extension of the stabilizer. The unexpected quick movement of the stabilizer to reach this extreme position could slam into mechanical stops and dislodge pipes, brackets or whatever, resulting in a mechanical jam that the pilots would be unable to deal with.

Here are specifics from MSNBC web site about the timing of the original problem:

http://www.msnbc.com/news/364560.asp

"At 3:55 p.m. PT, the plane, en route from Puerto Vallarta, was cleared to fly to San Francisco; it was the last routine transmission before the pilots indicated there was any problem.

At 4:10, the pilots acknowledged they were having difficulties and descended to 26,000 feet. A few seconds later, the flight descended to 23,750 feet and the pilots said they were having problems controlling the aircraft"

3. There have now been three planes with this problem, one has crashed and two have landed safely. News reports on the other two that had the problem:

Feb 2: http://www.msnbc.com/local/king/508850.asp

Feb 5: http://www.msnbc.com/news/364560.asp

When was the last time three planes all of the same make had essentially the same control surface problem within five days of each other and never before in their histories? The only two possibilities that I can come up with are identical faulty maintenance procedures or Y2K - the 4:00pm failure pushes me into thinking that this is a Y2K problem. Another oddity is that all three planes were on the west coast (California, Arizona, Reno) when they had the problem - maybe the software calculations fail if the date is greater than Feb 2000 and within a certain longitude window.

4. An MD-80 was known to have crashed years ago in China under the control of its autopilot - it landed short of the runway. This says that the autopilot can be a cause of a crash.

In any case, if my theory is correct, you should see the FAA ground all MD-80s very shortly or at least prevent them from flying on the West Coast.

I haven't presented this info to the NTSB since I don't know how to contact them, but I wouldn't be surprised if they are considering this angle also.

At the minimum, I hope you found my email interesting and at the best, I hope that quick action is taken by the appropriate parties to prevent further loss of life.

thanks, Roman Mach

******************************************************************

(end of quoted letter)

Comments, anyone?

-- abc (abc@ad.dc), February 19, 2000

Answers

Hawk, is that really you in the above article? It sure sounds like it.

Since the pilots were apparently having problems with the stabilizer shortly after takeoff, about an hour and a half before the 1600 time you quote, what does this do to the theory?

I think we've already put to rest the idea that the MD-83 is a "fly by wire" aircraft.

What is your source for the Chinese MD-80 landing while using the autopilot and crashing? I've seareched several aviation accident databases and can't find any evidence that this occured.

All in all, the letter is a mishmosh of theories based on a complete lack of understanding of how the MD-83 operates.

-- Jim Cooke (JJCooke@yahoo.com), February 19, 2000.

Nothing to worry about. Seems that Hawk has already convinced the airlines to replace their non-compliant chips, and they are grounding aircraft in droves to do so as described on this thread.

Removing tongue from cheek.

-- Mikey2k (mikey2k@he.wont.eat.it), February 19, 2000.

With my tongue in the middle of my mouth, the possibility of a Y2k bug being involved in the AS261 tragedy has been the topic of a number of threads on this forum. The Y2k theory (non-compliant chips in the autopilot/digital flight guidance system) has been disproven in this one.

-- Mikey2k (mikey2k@he.wont.eat.it), February 19, 2000.

My Dear Mikey,

Sir I am afaird that I must differ from your hastily drawn conclusions. In truth sir..None of us Know what caused the crash. And we either will never know (being we will never be told the truth). Or, sir..The athorities will anounce the cause.

I would, myself, have a closer look at the "housed" control functions of the servo motors for the stabilizer. I really rather believe that the control system in the motor, might have some interesting information for us. And thusly, we must again "return" to the question of embedded systems.

The three times the normal speed that it is stated that the screw jack moved (as opposed to the speed that it was designed for). Leaves a very large vacant area in your hypthosis concerning the other possible suspect areas of malfunction (s).

And it is also note worthy that many-if not all of the said air craft have been stood down for inspection.

"As for me...I shall finish the Game"!

~~~~~~~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~

-- Shakey (in_a_bunker@forty.feet), February 19, 2000.

Shakey,

Mikey2k is now consulting with the NTSB. He/She/It has decided that this was not y2k related, and has told the NTSB to wrap it up and go on to other things. Mikey2k is in charge here and will let us ALL know the status of any and all y2k matters.

Ray

-- Ray (ray@totacc.com), February 19, 2000.

I have worked on a bunch of DC-9's, (55 different N numbers by last count) Mostly heavy inspection and overhaul (C and D checks).

Many of these aircraft were nearly 30 years old with many thousands of cycles. I don't recall ever having "jackscrew" problems. This is not a normal failure mode for the "9".

It does some interesting things, though. Like cracking the "Trap Panel" (major wing attach structure), Antiskid brakes needing constant attention, nose gear strut needing frequent checks for wear.

Some of the failure modes are quite spectacular, like a blown tire on takeoff also results in a lost engine if the tire casing goes thru the engine.

Or the spoiler buckets deploying in flight. The will just depart the airframe if the speed is too high.

Back to the runaway trim, the real problem will probably not turn up. I would bet dollars to donuts there was a wiring short due to abraded insulation that sent full nose down power to the tail trim motor. Short of shutting down all elect power on the aircraft, there would be no way to stop the stab movement.

I have seen and worked on the wiring in these types of aircraft, it is not unusual to find wires with the insulation worn thru, and the wire bundle soaked in skydrol , grease, or fuel.

Like everyone else, I am just speculating, but it is usually the simple stuff that breaks.

Hope they find it AND tell the truth......

-- DC9 A&P (Beenthere@done.that), February 19, 2000.

Shakey, could you be more specific on what/where the ""housed" control functions of the servo motors" are, since we have a slightly different vernacular?

No, the stab trim did not move at 3x the speed it was designed for. It moved at the design speed for being driven by the primary motor, which is more than 3x the speed of the secondary motor which is the one being driven by the autopilot. So the suspect areas are factors that would apply electrical power to the primary motor, which do not include the autopilot. Now, if you can find a source (including the ones I referenced in my rebuttal) which indicate a computer involved in the control of the primary motor, then please point it out.

What is note worthy about the aircraft being stood-down for inspection? As a precaution, their trim actuators were inspected on and emergency basis (within a 3-day period) and then returned to service if no problem was found (most were). Sounds like some actuators were removed that need not have been.

No, I have not contacted the NTSB. They have the resources to make a finding without my input.

-- Mikey2k (mikey2k@he.wont.eat.it), February 19, 2000.