If you want to know why Constellation is such a godawful mess, here's one reason:
NASA JSC Center Director's Systems Engineering Forum Planned Aug. 21
There actually are people out in private industry (like me) who do this stuff for a living, or at least would, if NASA would give them a contract. But instead of putting out a SETA or some other support contract for systems engineering, as Steidle had planned to do, Dr. Griffin simply decided that NASA would do it. This is where it's gotten him. Had he hired a good SE contractor (and listened) the program would likely not be in the kind of trouble it is, either technically or politically. Of course, it would probably look much different, because a proper systems-engineering approach would never have resulted in the Shaft. That was the danger inherent in putting a rocket scientist in charge of the agency. He thought he was smarter than everyone else.
I dunno, this seems like a pretty innocuous excuse for a panel discussion. I doubt that much actual training will occur, it's more like coffee and donuts with the boys.
But it sparks a question -- back when I called myself a systems engineer for F119 (the F-22 engine), it seemed like systems engineers spent 90% of their time doing systems-level engineering (i.e. trade studies), and 10% doing program management (technical performance measures, schedule/budget/test planning, etc.). Now it seems flipped around -- 90% of systems engineering is the "soft" stuff like risk management and statistical schedule assessment, ROM costs, flowing down requirements from "Level n" to "Level n+1".... Is that your perception, too? Or did I always misunderstand what systems engineering is about?
In my experience (and I noticed this back in the late eighties, when I became a supervisor at Rockwell for systems engineering and mission analysis), the discipline has become all about bookkeeping requirements, and doesn't seem to require any knowledge of the systems being engineered. At least, to judge by the resumes and experience of many of the "systems engineers" with whom I dealt.
I'd like to believe that it's gotten better, but the opposite seems likely. Particularly if one is to judge by NASA's current manned space efforts.
"In my experience (and I noticed this back in the late eighties, when I became a supervisor at Rockwell for systems engineering and mission analysis), the discipline has become all about bookkeeping requirements, and doesn't seem to require any knowledge of the systems being engineered."
Precisely. "Systems Engineering" should be done by Chief Engineers and their deputies, not by kids just out of school using fill-in-the-blank spreadsheets. It has become a worthless clerical job that robs cycles and money from real engineers who time and attention are being wasted.
I've always viewed the systems engineer as the one that makes trade offs that cross disciplines.
The one person that has the BIG picture of the system and was responsible for the system performance.
In past lives I've seen project totally messed up via the bookkeeping systems engineer rather than the big picture thinker. The prime example was a requirement in a military system that all temperature measurements in the system be accurate to 0.5C from -55 to +125. Makes sense for a sensor, not so much for measuring the power supply heat sink temperature to look for blocked cooling or power supply failures.
+/- 5C would have been a better spec.
Having worked for two of the Big Three aerospace firms, I keep hearing rumors of places that do real systems engineering but I certainly haven't encountered it in real life. Most of the so-called systems engineers I've worked with just come to me (the flight controls lead) and say "please write these sections of the air vehicle spec, let me know when you're done, and I'll put in in the requirements database for you." It's a chicken-and-egg problem: they won't attract the people they need in the SE roles until they give them real work to do with real responsibility and authority, and they don't dare give such responsibility and authority to the clowns who actually work in the SE area.
Harrison Schmitt gave a talk at University Wisconsin-Madison at the invitation of our Nuclear Engineering and Engineering Physics Department yesterday. The talk gave an overview of the Constellation program.
He has had an Adjunct Professorship with that department, teaching a course in space resources (He3 hence the tie-in to Nuclear Engineering). He is currently employed by Orbital, but serves on something called the NASA Advisory Council.
The first question I asked was why "they" (NASA) were going with an Apollo-like Hohmann-style transfer from Earth to lunar orbit instead of staging at one of the L-points as had been proposed by one of the contractors during the early iterations. One of the NEEP department professors from a back row chimed in that the L-point rendezvous may be advantageous to go to Mars, but it was slightly less fuel-efficient than what NASA was proposing. I had heard otherwise but decided to take followup discussions with a member of the UW faculty "off line."
My second question or remark, which I asked after the dismissal of the seminar, was that "I had heard something" that the solid rockets posed some "concerns about vibration." Harrison Schmitt's response was that "all rockets had vibration problems, even the Saturn V had a pogo problem" and that "senior level design people" thought they had solutions.
I guess the somewhat disappointing thing was not so much that Harrison Schmitt presented the party line on the Constellation Program but that there wasn't perhaps some more energetic technical discussion. The concerns about the Stick aren't just those of some hobbyist cranks -- I understand there have been AIAA conference papers (i.e. scholarly sources) sounding the alarm about vigrous shaking of the Stick.
Much of the discussion was about RTGs, and the AIAA people here are mainly nuclear engineers and that is the technical issue of which they have the interest and expertise.
It may not be the role of students and faculty of the U to make a public scene with every guest speaker, but I was disappointed that there was not a more vigorous technical discussion given the issues.
One of the NEEP department professors from a back row chimed in that the L-point rendezvous may be advantageous to go to Mars, but it was slightly less fuel-efficient than what NASA was proposing. I had heard otherwise but decided to take followup discussions with a member of the UW faculty "off line."
It is higher delta vee to go to the moon via a Lagrange point. But there is much more to consider in the trade than delta vee.
Well, when I was at P&W, I was surprised at how few engineers really felt responsible for the whole engine. 97% of the folks just owned a part. Having said that, though, the engineers were very supportive whenever I would convene an ad hoc working group to work a problem. My usual mode of working was to wander the halls, sniff out problems, identify systems-level issues, assemble working groups, and git 'er done.
FWIW we also had a Chief Engineer's Office, which performed the function that NASA assigns to boards of "greybeards". (I noticed Bob Ryan was on the panel for the Webex that triggered this thread).
Nobody seems to do that at NASA. At least, I haven't run into them. There are people who take a "systems-level" attitude, notably the GN&C folks, but they are not empowered to go fix things, only to analyze them (and design the control system). There is a discipline called 'vehicle integration', but it is parallel to, not above, 'upper stage', 'first stage', etc. Curiouser and curiouser.
BBB
Nice rewrite of history, Rand. Systems engineering is a joke. Griffin is a systems engineer. He did a trade study and everything, just like a systems engineer would. Too bad he wasn't a rocket scientist. You remember rocket scientists, right? Guys like Von Braun. People who actually made a living DESIGNING ROCKETS instead of requirements documents. Systems engineering is just one more support function that gets in the way of real engineering. They're like IT. Thanks for getting in the way.
The Engineering Physics Department at the UW - Madison, hasn't been the same since Bud Schlack left and it reorganized, it's almost ALL nuclear engineers now. Even Astronautics (Engineering Mechanics) there is a mere shadow of its former self. I'm guessing none of them, faculty nor students, have a clue about the issues involved. There is little CFD skill left there as well.
Sorry I missed it, it would have been a scene for sure.
@Dfens:
Systems engineering AS IT IS CURRENTLY PRACTICED is indeed a joke; see my previous post. Far too many systems engineers practice the "waterfall" model of system development, where you derive ALL of the requirements before you do any design at all. A smart systems engineering process will allow for lots of iteration in requirements, because the day you know all the requirements is the day the system is retired to the museum or the boneyard. Sadly, the iterative approach takes real systems engineers, which is difficult because of the chicken-and-egg problem I discussed. There is an exact analog of this problem in SW development (the methodologies and processes of which are often incestuous with SE), and is one of the major causes of late SW development programs - see Fred Brooks's classic "The Mythical Man Month". The rise of the Software IPT makes this problem worse. I've been threatening to write a white paper titled "Software IPT Considered Harmful in Development of Flight Critical Systems" for over ten years now; maybe it's time I really wrote it :-/.
@bbbeard:
A good GNC engineer (which I try to be most of the time) MUST be a good systems engineer in the true sense of the word: there's just about nothing on the vehicle that GNC doesn't touch - one of the reasons I enjoy it so much. As far as being empowered to fix things: "it's better to get forgiveness than permission." :-/
Systems engineering is crap and has always been crap. It's not engineering. It's a job for "shall statement" bean counters. If linked lists turn your crank, you should be a systems engineer. Any requirement written without a design to support it is bs. You don't iterate requirements, you iterate the design then write the requirements. These dumbass systems engineers would have us replace engineering drawings with their idiotic "shall statements". Ironic how back in the day we talked seriously about eliminating drawing notes with 3D CAD model surface attributes. Today there are a thousand companies scattered around the beltway all promising that if you put enough "shall statements" into their database a drawing will magically appear. What a crock! If these idiot systems engineers had their way they'd turn all real engineers into monks living in caves writing millions of "shall statements" to fill their endless need for databases and documents. And the deeper the crap has become, the longer it takes to produce anything. Hell, Kelly Johnson must be spinning in his grave.
You don't iterate requirements, you iterate the design then write the requirements.
This explains so much about your fears written here. Pray tell what is the rationale for reiterating the design?
Just to add a I told you so. One of the big failures of the Space Station Freedom Program (which I was on) was NASA didn't get the basics of systems engineering, or how to manage a big development program. It got bad enough they canceled the whole program and turned the remains over to Boeing to salvage and make the ISS out of. So I was real dubious when Griffin insisted NASA had to be the prime contractor and systems integration led for all future major programs.
Hint
Systems engineering is clearly and unambiguously defining what “it” must do, then what all the parts must do to support the “it” level needs, etc. Defining unambiguous tests to conclusively show all the parts, subassemblies, assemblies, etc all the way up are actually working. Making sure you didn’t drop something through the cracks, etc.
If that strikes a “real engineer” as a waste of time, they probably shouldn’t try doing anything complicated. Lord knows I’ve been no programs where (direct quote here from a senior exec to the head of the SE department) “system engineering’s just paperwork the customer wants, don’t get in the way of real engineers doing real work.” And such programs (that one in particular) tend to fail, or have explosive tail end costs to fix problems missed earlier.
Dfens wrote:
"Systems engineering is just one more support function that gets in the way of real engineering. They're like IT. Thanks for getting in the way."
I'll be sure to let your helpdesk guys know how you feel the next time your system crashes. They will go all 'Sysadmin from Hell' on your ass.
Oh, wait they probably already know. People think they are so witty and clever when they call a helpdesk. That idiot SOB helpdesk analyst has a mute button and a speaker phone. Those "gifted" individuals that call get to have their lovely opinions broadcast to the whole group. Makes for great entertainment.
When you get paid for process it feeds the cancer that is systems engineering. When you get paid for results the process guys go away and the real engineers take over. NASA pays for process and their leader is Mr. Process. Seems appropriate to me. Systems engineers are always bleating about how things would be different if they were in charge. Yeah, things are different all right. Nice job, losers.
Josh,
Now you know why he uses a pseudonym. Alas, we can all get a laugh even if his sysadmins don't know for sure if this is the same gifted person.
Scott Adams could use his comments as material for a new Dilbert book.