Откъслек от старо писмо... / Наука / Технически науки / Авиация

Rookies did analysis of damage to shuttle, Boeing engineers say
Seattle Times 02/23/03
author: Joe Mozingo / Knight Ridder Newspapers
(Copyright 2001)

HUNTINGTON BEACH, Calif. - Veteran Boeing engineers say their company falsely led NASA to conclude that the space shuttle Columbia was safe to land because top managers assigned the task of assessing damage to employees who never had done that type of analysis for the space agency.

"I think they wanted to paint a rosy picture, and they did," said a thermal-systems engineer who did such analysis for 10 years in California before Boeing shifted the work to its Houston offices last year. "In my experience, I have never seen a strike this big."

Interviews with engineers at the Boeing plant in California bolster outside experts' claims that the company grossly erred in its evaluation of wounds the shuttle may have received when debris slammed its left wing during liftoff.

In one internal e-mail circulating among California engineers, an unnamed employee speculated that NASA is downplaying the debris strike to fend off criticism it might not have done enough to get the astronauts back safely.

"The NASA boys are 'back-pedaling' on the original theory of debris impact," the Boeing employee wrote. "I think they are trying to build a case to protect their asses for running with faulty thermal analysis."

It is still not clear what caused the shuttle to disintegrate over the Southwest. An independent panel investigating the disaster has determined only that some type of breach allowed searing gases to enter the shuttle and melt its aluminum frame.

Thermal-protective tiles are believed to have been damaged or missing, leaving the ship's thin aluminum skin vulnerable to a "burn-through."

NASA officials have said the breach also might have resulted from contact with debris while in orbit, or from a problem that originated within the shuttle.

Most speculation, however, has centered on debris that sloughed off the external fuel tank and hit the wing 81 seconds into launch.

Engineers began focusing on this possibility while the Columbia was still in orbit. Boeing was asked to evaluate whether the damage could flare up into a burn-through during re-entry.

Engineers at Boeing's plant in Huntington Beach say they had done these analyses for 20 years, but were not asked this time.

The reason, they say: Boeing transferred shuttle jobs to Houston in a consolidation that cost the company scores of its most experienced shuttle engineers in the past two years - including some who invented the methodology for debris damage and thermal analysis.

Of 1,300 jobs in Boeing's shuttle program nationwide, 500 were transferred last year from California, officials said. Only 100 people actually made the move; scores of veteran engineers left the company or stayed behind, doing other work, according to Boeing spokeswoman Kari Allen. (Това прави Скромно Ваш един от 100-те; брей, и аз да стигна 1% от някоя статистика!)

So as the clock was ticking toward the Columbia's re-entry, Boeing managers relied on a Houston-based team of engineers who never had done this type of analysis in a real situation.

"This was their first flight," the Boeing thermal-systems engineer said. "This was the first time they took over." (Наблягането на топлинни системи, не на аеродинамика или газ-динамика; някой е казал на журналиста да не прекалява с обобщенията; много силно!)

Allen said Friday she didn't know if that was true. "There's a whole lot of people who put that analysis together. Just because there were four names on the front doesn't mean there weren't many other people." (Та значи, докладът вярно имаше 4 имена; тия от вестника четат материал, чието изнасяне извън Боинг и НАСА си е престъпление.)

The Houston team analyzed numerous scenarios, ultimately predicting a "safe return." Boeing executives have defended that analysis as the "best answers possible" from the "best technical minds." Allen said Friday the company "absolutely" stood by that statement, even as new e-mails released from NASA last week suggested some inside the agency voiced strong doubts.

The California engineers, however, say the Boeing team in Houston grossly misanalyzed the data.

Several California engineers began conducting their own analysis after the crash, using the same data and procedures used in Houston. Their results are not only different, but they indicate that NASA had an emergency on its hands.

"We're redoing the analysis because we think it needs to be done differently," said another longtime shuttle engineer, an expert at calculating debris impact. "The re-analysis is finding things to be more harsh than the original." (Проблемът е, кой е този експерт? Истинският експерт пострада от инсулт преди няколко години и едва може да каже две думи на кръст; той си приказва, де, но никой не може да го разбира. Друг експерт няма. Има любители и плямпачи, минавали покрай отпечатките на анализите. Някой от тях да се е възпроизвел на експерт?)

Said the thermal-systems engineer: "Basically, they just didn't interpret the numbers right. They never properly identified the risk."

Four Boeing employees and contractors spoke for this report. Each has at least a decade of experience with the shuttle program. They asked to remain anonymous because they said company vice presidents ordered them not to talk to the press.

Their interviews echo the statements of numerous outside experts who have said the thermal analysis was flawed. And they raise a daunting question in the aftermath of Feb. 1: Could NASA have saved the seven astronauts had it assessed the risk properly?

NASA successfully landed a damaged shuttle at least once before after cooling the vulnerable part before the shuttle's fiery re-entry. When an oxygen tank exploded on Apollo 13 in 1970, astronauts made a series of makeshift fixes to survive.

"If they had the right risk information, what do you think they'd start to do?" asked Paul Fischbeck, a Carnegie-Mellon professor who studies risk in engineering systems and researched debris impact on the shuttle for NASA. "They would start getting very creative in how to solve the problem. But it's critical you know all the risks."

After the disaster, the California engineers were shocked to see the data that Boeing and NASA used to reach their conclusions. One chart relied on a computer program called "Crater" to come up with nine damage scenarios. Any one of them could have been catastrophic, the thermal engineer said, but the Houston analysts downplayed the results by saying that "Crater" tended to be conservative.

Outside experts say it made no sense to reject methods that brought other shuttles home.

"I don't understand how they can run the Crater program and get these results and discount them completely," Fischbeck said.

Worse still is that the evaluation, completed Jan. 23, was done on the basis of one piece of debris hitting the shuttle. Yet a debris-impact analysis completed Jan. 24 showed that three pieces of debris may have struck the orbiter.

It's unclear whether the consequences of the latter circumstance were addressed.

NASA consistently has tried to downplay the possibility that damage caused by the debris led to the crash. NASA Administrator Sean O'Keefe mocked reporters last week for focusing so much on foam, calling them "foamologists."

But the internal e-mail circulating among Boeing employees in Huntington Beach shows that at least some have doubts: "NASA and Boeing management are doing whatever they can to redirect attention away from that thermal analysis that was done by inexperienced thermal engineers rather than the guys that would normally have done it." (Пак уточняването за топлинни натоварвания! Журналистът не се е раздраскал по вестникарски; евала му прайм!)

Boeing did indeed worry that the move to Houston could lead to a loss of knowledge in the shuttle program. When the company realized that employees were not going to move to Houston, they set up a "Knowledge Capture Program" to prevent a brain drain.

"What happened with these people who didn't want to move, they had trainers who took a lot of the information they had," Boeing spokesman Ed Memi said. "These trainers were then responsible for making sure replacement personnel were up to speed."

A former shuttle subsystems manager who works for Boeing in California called the Knowledge Capture Program "a total joke." (Цитираният джентълмен го познавам; готин пич, бивш от ВВС.)

"First of all, lots of people jumped ship before that was even implemented," he said. "Second, all they did was send out a questionnaire, and we were supposed to put 20 years of knowledge on a questionnaire?" (Същият въпросник го попълни и Скромно Ваш; извадки следват по-долу...)

============================================================
И ето извадки от въпросника по "Знание Пленяване". Въпросите са писани от гений с титли по психология и други подобни полета тясно свързани с аналитично инжинерство; отговорите са писани от Скромно Ваш, като правите сметка, че тези отговори бяха поне написани (сиреч, уважил съм въпросите, та чак им отговарям), и са твърде учтиви - в сравнение с отговорите от други, чието знание трябваше да бъде "пленено"...)

1.3 What policies or procedures or other types of documentation are in place that describes your job?
If there are any, they will be incomplete and/or obsolete.

1.6 How do you manage risks in your function?
Competent analytical work relegates risk to a statistical variable of limited impact; therefore, risk was never allowed to become a serious factor in my analyses.

1.9 Which reports, books, and/or journals would you recommend to someone new who's trying to get familiar with this hardware? Were there two or three reference reports or books that you found yourself using several times during the program?
All the available publications of Rockwell SSD / BNA / Boeing HSF&E plus lots of related NASA information and research publications. On the other hand, if a person has the brains to do this - what is s/he doing in aerospace engineering?!

2.1.6 How do you judge the quality of the knowledge (timeliness, usefulness, validity of source, etc.)?
The knowledge, documented and available as described above, allows a MECHANICAL execution of the tasks for NOMINAL conditions. Actual deeper understanding of the processes and knowledge involved, for response to aberrant conditions, can take years.

2.1.7 Do you need to determine if the knowledge is correct and current? If yes, how do you do that?
If the knowledge is not correct and current, the analytical algorithms will fail. Or will generate flawed results that will require intricate diagnostics over countless man-hours! Therefore the knowledge MUST be correct and current!

On the other hand, because I created much of the knowledge described, and I keep it updated, I determine if the knowledge is correct and current by looking into a mirror and asking myself if the knowledge is correct and current.

2.1.8 How frequent do you access this knowledge (hourly, daily, weekly, monthly, etc)?
1. With the performance of each analysis for each flight.
2. With each update to respond to changes in analytical procedures, in databases, in program codes, in interface / control scripting, and in computational environment.

2.1.9 How do you access this knowledge?
By reading (my own) user guides and documentation and executing (my own) interface / control scripts to active (written, modified and/or updated by me) codes.
Someone else will have to follow my user manuals line-by-line! And will have to read up on years of adjunct documentation.

3.1 Do you (or does your organization) have trade secrets, special recipes, and other things you can do that other organizations can't do? If so, how and where are they captured and stored for future use?
Yes. Highly capable working people. They can be captured by pay, commensurate with their qualifications, and no, they cannot be stored.

3.2 How do you capture "lessons learned" and how do you obtain the lessons-learned from others?
This is an individual process, based on informal personal interchange. "Lessons learned" is not a subject overly fitting documentable exposure.