-
#400
by
JEF_300
on 30 Dec, 2019 13:46
-
except there was a clearly identified problem THAT WAS IGNORED.
Ignored by the "right people". That was the point.
Again, scare tactics. You have no insight to claim such things.
You should, again, be ashamed that you are drumming up fear and doubt for your own personal forum/internet likes.
My "own personal forum/internet likes"? Are you kidding? I could really care less if I got any likes at all. I don't need or want any "likes". I don't give a rat's ass about any of that crap. I can't remember if I have ever looked to see if I got any, because I really don't care. I speak my mind and if someone likes or doesn't like what I say well that's on them and has zero effect on me.
And it's not scare tactics. It's established fact. Challenger should not have launched. The "right people" were advised strongly not to launch. They were told by the engineers that the temperature was below the safe minimum. Yet they decided to launch anyway. Why? Schedule pressure. I've felt that kind of pressure. It can be unbelievably brutal at times. All I said was I hoped today's batch of the "right people" wouldn't succumb to that kind of pressure the way others have in the past. That is not a scare tactic. It's a prayer.
And I never indicated that I was some kind of expert on Starliner, from one of your earlier posts. I've no idea where that came from.
Emphasis mine.
Chuck is entirely correct. Just read the final report of the Rogers Commission's investigation into the Challenger accident:
https://spaceflight.nasa.gov/outreach/SignificantIncidents/assets/rogers_commission_report.pdf
It clearly spells out that substantial pressure from top NASA management, to meet flight schedules, is what cost the lives of 7 US astronauts.
As such, Chuck raising the red flag with regards to CCP schedule pressure is fully and wholly justified IMO.
This is more of a comment on the Challenger conversation in general than this specific post.
If we eventually want spaceflight to really (pardon the pun) take off, the launch rate is going to have to increase dramatically, and that will inevitably result in schedule pressure.
With that in mind, one takeaway I always had from Challenger was that despite the imense schedule pressure, the engineers still made the right call. So as long as managers
just don't overrule their engineers, it doesn't matter how much schedule pressure there is!
Obviously,
just don't is something much more easily said than done, but trusting the engineers is a start that can be worked from.
I suppose that's the difference between the ya'lls perspective and mine. I believe we can always trust the engineers, inspite of schedule pressure.
(This perspective presents some questions about who in an organization is an engineer and who's a manager [i.e. is the engineer managing engineers a manager or an engineer?], but that's a whole conversation of it's own.)
That's the mindset I'm using in regards to Starliner. I think being concerned about schedule pressure on Starliner is valid, but I personally won't start to be really concerned until we see evidence that the engineers working on Starliner also think there should be an OFT-2. Everything I've seen so far suggest that their on board with the next flight being the CFT.
-
#401
by
otlski
on 30 Dec, 2019 14:51
-
Where did the 1.4 km number come from?
Yes. I would like to know this too. What is the source of the 1.4 km claim?
-
#402
by
Comga
on 30 Dec, 2019 14:58
-
Chuck knows this stuff better than most anyone here but I respectfully disagree.
For one, this is the Starliner thread, not the Dragon thread. Bridenstine’s flat out boosterism of Starliner doesn’t seem schedule driven as much as coddling Boeing.
“Insanity is doing the same thing and expecting different results.” The USAF told Boeing and Lockheed that “dissimilar redundancy” was an absolute need so they told the Air Force how much money they wanted to provide it. We got EELV with $1B per year “support”.
Now Bridenstine tells Boeing their participation in Commercial Crew is absolutely needed and asks how much they want to provide it.
“One line of bad code in OFT”? Press on to a long duration CFT and four operational missions!
For another, Commercial Crew is neither Apollo, with its presidential mandate of “before the decade is out” nor Shuttle, where few missions if any were time critical but delays looked bad. There is genuine urgency to support our $100B ISS, and NASA should be working to the schedule. (All impediments are understood and serious.)
Over in the Dragon 2 threads there is discussion of NASA having “Stop fever”. Three more reviews after the IFA, assuming it is successful, before DM-2. And no discussion of how long these will take. Safety is paramount!
So no, IMO this is not like Challenger. In NASA’s hydra-headed way it’s both more heedless of problems and more timid. It depends on which of the “more equal than others” side you look at.
-
#403
by
Comga
on 30 Dec, 2019 15:02
-
Where did the 1.4 km number come from?
Yes. I would like to know this too. What is the source of the 1.4 km claim?
I can’t search for it now but there was a plot of the landing zone shown in a few of our NSF threads with concentric rings at 1km radial intervals, a red ring at 5 km (probably the “requirement“) and a statement of 1.4 or 1.3 km offset from the center.
-
#404
by
clongton
on 30 Dec, 2019 15:15
-
Chuck knows this stuff better than most anyone here ...
Just for context, there are many, many on this site far more knowledgeable and experienced than me. I know who they are and when they chastise me I take it seriously. If I disagree then I (usually respectfully) say so in no uncertain terms, but that doesn't lessen my respect for their experience and knowledge. OM72 comes to mind. We've known each other for a long time.
-
#405
by
teetlebomb
on 30 Dec, 2019 15:19
-
Where did the 1.4 km number come from?
Yes. I would like to know this too. What is the source of the 1.4 km claim?
I can’t search for it now but there was a plot of the landing zone shown in a few of our NSF threads with concentric rings at 1km radial intervals, a red ring at 5 km (probably the “requirement“) and a statement of 1.4 or 1.3 km offset from the center.
"Bullseye landing!"
https://forum.nasaspaceflight.com/index.php?topic=49678.msg2028967#msg2028967
-
#406
by
Comga
on 30 Dec, 2019 16:21
-
Where did the 1.4 km number come from?
Yes. I would like to know this too. What is the source of the 1.4 km claim?
I can’t search for it now but there was a plot of the landing zone shown in a few of our NSF threads with concentric rings at 1km radial intervals, a red ring at 5 km (probably the “requirement“) and a statement of 1.4 or 1.3 km offset from the center.
"Bullseye landing!" https://forum.nasaspaceflight.com/index.php?topic=49678.msg2028967#msg2028967
Thank you!
After not finding it I was worried it was from L2 but no, there it is.
1.36 km
I don’t make stuff up.
-
#407
by
Rocket Science
on 30 Dec, 2019 16:36
-
Regarding Starliner's failure to reach orbit. There is some information that allows us to guess a little about how Starliner's software works. This is only an educated guess.
First some events seemed to happen on time and others did not. It sounds like there are multiple timers in use.
Another piece of information is that, for things to work, RCS eliminating dead space and OMT burn, events are synchronized across multiple timers. This brings up several questions:
1. The RCS system went into dead space elimination without the OMT firing means that there is no master state machine providing events to subsystem state machines. Is this true? In other words, how was the RCS acting as if OMT was firing when it wasn't unless they are separate and not communicating?
2. Does this mean multiple software platforms having to synchronize?
3. Does this mean multiple software systems running os different hardware stacks?
If the answers to 1,2, and 3 is true then did Boeing cobble Starliner out of at least some existing controllers?
Welcome to the forum!
-
#408
by
AJW
on 30 Dec, 2019 17:47
-
We keep being told that there was no failure in Atlas, but I take a different view. No matter the spin, OFT failed the mission objectives. We are told that the fix for the MET issue is simple. Same message after the abort test. A million things have to go right, and yet any one sometimes-simple mistake can lead to mission failure. These are process failures and one of the weaknesses of Process Failure Mode Effects Analysis (PFMEA or sometimes just FMEA) is that when the number of products or ‘experience’ is low, and the severity or risk of any single process step is high, you are forced to rely almost entirely on detecting problems, but this make any failure to detect an issue a new failure point. As has been demonstrated, you have a system that is at a high risk of failure by even a simple, easy to address mistake. This is one of the key reasons why ‘rockets are hard.’
The solution to this problem is repetition or ‘experience’. Build a million widgets, fly lots of test flights, get actual occurrence values, study and address these, and you can lower the overall risk. This is why our cars are more reliable, our airline industry is safer (Max snark aside), and the products we buy mostly work as expected.
This leads to my assertion that Atlas is part of the problem. When you have a failure with a system, you address that failure and try it again. This is why ‘Test like you fly’ has been a mantra in the industry. When you fly infrequently, testing must take on the burden of repetition or experience when frequency is so small. Unfortunately the cost of Atlas makes repetition and iteration impractical. While Atlas itself has proven to be very reliable, it has become that way through iteration. Sadly, it has created a barrier where launching a payload is so costly, that even when faced with a mission failure, it becomes impractical to redo even a test flight. As a result, each chain will be as weak as its weakest link, and that link is a simple as looking up the wrong coefficient.
-
#409
by
Newton_V
on 30 Dec, 2019 19:20
-
This leads to my assertion that Atlas is part of the problem. When you have a failure with a system, you address that failure and try it again. This is why ‘Test like you fly’ has been a mantra in the industry. When you fly infrequently, testing must take on the burden of repetition or experience when frequency is so small. Unfortunately the cost of Atlas makes repetition and iteration impractical. While Atlas itself has proven to be very reliable, it has become that way through iteration. Sadly, it has created a barrier where launching a payload is so costly, that even when faced with a mission failure, it becomes impractical to redo even a test flight. As a result, each chain will be as weak as its weakest link, and that link is a simple as looking up the wrong coefficient.
ULA has no insight into what goes on downstream during Integrated Systems Tests. ULA DOES Test Like You Fly. You're describing Fly to Test, or Fly Like you Test. No other customers, including ones who fly with interleaved telemetry, have any problems, mainly because THEY do the tests they need to do. Somebody messed up here, and it has nothing to do with Atlas.
I can't think of any other launch vehicles that did another test flight after a problem. Delta IV Heavy Demo, AV-009, OA-6, CRS-X, AMOS-6: Those all flew real payloads after LV! failures and anomalies.
Are you suggesting SpaceX should have flown a test flight after Zuma because of somebody else's screw-up?
If CST-100 was flying on a Falcon, the response from Boeing would be exactly the same regarding the need to re-fly another OFT mission vs. a CFT mission.
-
#410
by
jarmumd
on 30 Dec, 2019 20:47
-
To answer another random statement upthread, this is not an unproven NDS. It was exercised on orbit by Starliner and this is the same docking system (hence the word common that is sometimes used) SpaceX uses with Dragon.
I thought Boeing and SpaceX were using different hardware implementations of the same standard?
It's the same system at the root. Otherwise it could not be a common interface.
Can Dragon and Starliner dock with each other?
In theory. It depends ultimately the dash number configurations being flown. There is one dash number that cannot mate to its identical config. There is another that cannot act in passive mode.
sorry this is a few days late.
The soft capture ring and parts of the latching and hooking mechanism are the same. The attenuation and retraction systems are completely different. Some of the sensors are different. Any parts that touch the ISS are the same - that's the point of a standard - but most everything behind those parts are different.
No, no current system can do androgynous docking. The future NDS-B2 might have it, but I'm not sure how it deals with the sealing issues that come from seal mating to seal, instead of a seal to a flat surface (like on the ISS).
I think the point is that the NDS-B1 is a test proven docking mechanism, but it hasn't been proven that the whole system of Starliner and docking mechanism can work integrated, on-orbit. Having said that, I don't think there is any reason to do a unmanned test just for the docking system. At this point it doesn't matter if it's manned or not, it's going to be an unknown unknown that gets you, and docking gets so much attention and analysis that the crew risk would be low (for the docking event in particular).
-
#411
by
otlski
on 30 Dec, 2019 21:15
-
Where did the 1.4 km number come from?
Yes. I would like to know this too. What is the source of the 1.4 km claim?
I can’t search for it now but there was a plot of the landing zone shown in a few of our NSF threads with concentric rings at 1km radial intervals, a red ring at 5 km (probably the “requirement“) and a statement of 1.4 or 1.3 km offset from the center.
"Bullseye landing!" https://forum.nasaspaceflight.com/index.php?topic=49678.msg2028967#msg2028967
Thank you!
After not finding it I was worried it was from L2 but no, there it is.
1.36 km
I don’t make stuff up.
Thank you! I checked the assumption that the circles were 1 km each and they checked out. The 1.4 km analysis looks valid. BTW - I meant nothing nefarious by the word "claim".
-
#412
by
LouScheffer
on 31 Dec, 2019 00:51
-
This leads to my assertion that Atlas is part of the problem. When you have a failure with a system, you address that failure and try it again. This is why ‘Test like you fly’ has been a mantra in the industry. When you fly infrequently, testing must take on the burden of repetition or experience when frequency is so small. Unfortunately the cost of Atlas makes repetition and iteration impractical. While Atlas itself has proven to be very reliable, it has become that way through iteration. Sadly, it has created a barrier where launching a payload is so costly, that even when faced with a mission failure, it becomes impractical to redo even a test flight. As a result, each chain will be as weak as its weakest link, and that link is a simple as looking up the wrong coefficient.
Are you suggesting SpaceX should have flown a test flight after Zuma because of somebody else's screw-up?
I think the point is that Northrop Grumman should have had a test flight to try their separation mechanism before risking a (supposedly) billion dollar mission on it. But if launches are expensive, engineers will try to minimize the number of test flights. The fewer the test flights, the greater reliance on simulation and inspection. This increases the risk of a previously un-discovered bug.
There are examples of missions launching prototypes to test technologies. LISA, Galileo, and Starlink come to mind. I think all of these have paid off in experience gained. If launches were cheaper, more real-life testing would take place, and the systems would be on the whole more reliable.
In the CST-100 case, I'd guess the cheapest possible re-flight is more than $100M (Atlas with 2 solids and two RL10s). That's enough to give anyone pause before ordering a do-over. SpaceX, at $50M for a minimal flight, would be more appealing, but likely not appealing enough in my opinion. I'd guess, though, if a re-do was $20M then it would be seriously considered.
-
#413
by
CyndyC
on 31 Dec, 2019 01:39
-
I don't know the format of the interface between the Atlas and the Starliner, but I wouldn't be at all surprised if it was really primitive--like, "send me what's at this address" primitive.
That'll work fine, as long as both the Atlas and Starliner builds are synchronized, so that the proper pointers are exported from the Atlas side to the Starliner side before the Starliner stuff is compiled and linked. But if you get a last-minute Atlas build that isn't accompanied by a corresponding Starliner build, then you're going to have a problem. Since those builds are coming from two different organizations, it's easy to envision a process oopsie occurring that leaves the pointers out of sync....
The above a few days ago and someone questioning the integrity of the Atlas V again today. A paragraph in I believe one of many SFN articles about Starliner briefly mentioned how much work went into human rating the Atlas V, and in the process of trying to find the paragraph again, I came across even bigger news on that. According to an article right here on NSF by our very own Chris Bergin, an agreement was reached to human rate the Atlas V for commercial crew beginning as long ago as Feb 2011, including for CST-100.
By the same article I was reminded that ULA began as a joint venture between Lockheed Martin and none other than Boeing. There would have to be some amount of compatibility already in place resulting from heritage.
https://www.nasaspaceflight.com/2011/07/nasa-ula-saa-complete-human-rating-atlas-v/
-
#414
by
Newton_V
on 31 Dec, 2019 01:45
-
I think the point is that Northrop Grumman should have had a test flight to try their separation mechanism before risking a (supposedly) billion dollar mission on it. But if launches are expensive, engineers will try to minimize the number of test flights. The fewer the test flights, the greater reliance on simulation and inspection. This increases the risk of a previously un-discovered bug.
There are examples of missions launching prototypes to test technologies. LISA, Galileo, and Starlink come to mind. I think all of these have paid off in experience gained. If launches were cheaper, more real-life testing would take place, and the systems would be on the whole more reliable.
In the CST-100 case, I'd guess the cheapest possible re-flight is more than $100M (Atlas with 2 solids and two RL10s). That's enough to give anyone pause before ordering a do-over. SpaceX, at $50M for a minimal flight, would be more appealing, but likely not appealing enough in my opinion. I'd guess, though, if a re-do was $20M then it would be seriously considered.
Missions like OFT, the Z mission, and other "commercially procured" missions have much less (or no?) government oversight and things like this happen more often because nobody is on contract to do IVV and a more complete integration (for lack of a better description) of the mission. I'm not arguing either way how things should be done, but that's just what you're seeing here. I suspect you will see more of this in a more cost competitive environment. Faster, better, cheaper: Pick one.
-
#415
by
Newton_V
on 31 Dec, 2019 02:08
-
By the same article I was reminded that ULA began as a joint venture between Lockheed Martin and none other than Boeing. There would have to be some amount of compatibility already in place resulting from heritage.
Not necessarily, as all the Boeing Delta employees and the Lockheed Martin Atlas program became ULA.
Also to note, Boeing has flown satellites on Atlas V with the heritage avionics, on Delta with its heritage avionics, and on both vehicles with Common Avionics.
Both LM and Boeing satellite programs were fire-walled off from the LV side when ULA was formed.
-
#416
by
AJW
on 31 Dec, 2019 16:13
-
ULA has no insight into what goes on downstream during Integrated Systems Tests. ULA DOES Test Like You Fly. You're describing Fly to Test, or Fly Like you Test. No other customers, including ones who fly with interleaved telemetry, have any problems, mainly because THEY do the tests they need to do. Somebody messed up here, and it has nothing to do with Atlas.
Back in the 80's while doing R&D under Dr. Alan Kay I interviewed and hired an engineer who years later developed the JSON format. We had both worked on a wide variety of processors, often with different native 'word' size and endianness, either of which could play havoc with inter-machine comms. JSON was easy to parse, machine and language independent, and far less prone to errors, and as a result it is now one of the significant pieces of tech that makes the internet world turn. To quote a TV commercial of that time, "You're soaking in it."
ULA may never reveal how they 'messed up', as you describe it, but the interface belongs to Atlas. If that interface is prone to error, then yes, there is a problem with Atlas. If I was working on DC for CRS-2, I'd be checking every line of code that talks to that interface and reconfirming each 'coefficient' (whatever that actually means), it's name, definition, location, size, endianness, range, and while at it, I'd send a high level request to insure that the spec I was working on was actually the final spec. If I was testing the interface, I wouldn't settle for an emulator or a bench system, I'd schedule runs on the actual flight hardware. If I was Boeing, I'd be looking at that interface in order to understand why it was easily misinterpreted and resulted in a mission that failed to meet its objectives.
-
#417
by
Newton_V
on 31 Dec, 2019 18:15
-
ULA may never reveal how they 'messed up', as you describe it, but the interface belongs to Atlas. If that interface is prone to error, then yes, there is a problem with Atlas. If I was working on DC for CRS-2, I'd be checking every line of code that talks to that interface and reconfirming each 'coefficient' (whatever that actually means), it's name, definition, location, size, endianness, range, and while at it, I'd send a high level request to insure that the spec I was working on was actually the final spec. If I was testing the interface, I wouldn't settle for an emulator or a bench system, I'd schedule runs on the actual flight hardware. If I was Boeing, I'd be looking at that interface in order to understand why it was easily misinterpreted and resulted in a mission that failed to meet its objectives.
Please stop making things up. ULA did not mess up, as you are trying to imply. What does that even mean: "the interface belongs to Atlas". It's not prone to error and there is not a problem with Atlas. You seem to want to create an issue on the LV side where there isn't one. The spacecraft was separated into the exact orbit the customer specified.
There are Interface Control Documents (ICD) that specified all the requirements. There are also a Mechanical ICD that specifies the hardware interface requirements (assuming ULA provides the sep system) and an Electrical ICD to specify things like connectors, pins, commands, etc. All documents are signed by both parties and very clearly describe how the verifications of the requirements are to be met.
Why don't you wait until the postflight analysis is complete before you start negatively speculating (or wishing) that ULA did something wrong.
-
#418
by
jjyach
on 31 Dec, 2019 18:34
-
ULA may never reveal how they 'messed up', as you describe it, but the interface belongs to Atlas. If that interface is prone to error, then yes, there is a problem with Atlas. If I was working on DC for CRS-2, I'd be checking every line of code that talks to that interface and reconfirming each 'coefficient' (whatever that actually means), it's name, definition, location, size, endianness, range, and while at it, I'd send a high level request to insure that the spec I was working on was actually the final spec. If I was testing the interface, I wouldn't settle for an emulator or a bench system, I'd schedule runs on the actual flight hardware. If I was Boeing, I'd be looking at that interface in order to understand why it was easily misinterpreted and resulted in a mission that failed to meet its objectives.
Please stop making things up. ULA did not mess up, as you are trying to imply. What does that even mean: "the interface belongs to Atlas". It's not prone to error and there is not a problem with Atlas. You seem to want to create an issue on the LV side where there isn't one. The spacecraft was separated into the exact orbit the customer specified.
There are Interface Control Documents (ICD) that specified all the requirements. There are also a Mechanical ICD that specifies the hardware interface requirements (assuming ULA provides the sep system) and an Electrical ICD to specify things like connectors, pins, commands, etc. All documents are signed by both parties and very clearly describe how the verifications of the requirements are to be met.
Why don't you wait until the postflight analysis is complete before you start negatively speculating (or wishing) that ULA did something wrong.
Exactly it is the payload's responsibility to adhere to the ICD and to test/review towards it. As Newton mentioned above this was in no way ULA's fault. ULA provides the external interface, and if you want to fly anything on them, or any other flight vehicle you have to do the work to meet that interface/spec and ensure before flight it works. Same goes if you deliver your own sep system, and some thing in it fails to work correctly, the launcher isn't at fault when the problem is past their line of demarcation.
-
#419
by
TheRadicalModerate
on 31 Dec, 2019 20:23
-
ULA may never reveal how they 'messed up', as you describe it, but the interface belongs to Atlas. If that interface is prone to error, then yes, there is a problem with Atlas. If I was working on DC for CRS-2, I'd be checking every line of code that talks to that interface and reconfirming each 'coefficient' (whatever that actually means), it's name, definition, location, size, endianness, range, and while at it, I'd send a high level request to insure that the spec I was working on was actually the final spec. If I was testing the interface, I wouldn't settle for an emulator or a bench system, I'd schedule runs on the actual flight hardware. If I was Boeing, I'd be looking at that interface in order to understand why it was easily misinterpreted and resulted in a mission that failed to meet its objectives.
Please stop making things up. ULA did not mess up, as you are trying to imply. What does that even mean: "the interface belongs to Atlas". It's not prone to error and there is not a problem with Atlas. You seem to want to create an issue on the LV side where there isn't one. The spacecraft was separated into the exact orbit the customer specified.
There are Interface Control Documents (ICD) that specified all the requirements. There are also a Mechanical ICD that specifies the hardware interface requirements (assuming ULA provides the sep system) and an Electrical ICD to specify things like connectors, pins, commands, etc. All documents are signed by both parties and very clearly describe how the verifications of the requirements are to be met.
Why don't you wait until the postflight analysis is complete before you start negatively speculating (or wishing) that ULA did something wrong.
I agree that this is not a ULA problem, but I am curious how robust the interface is. Do you know its details?
My last true aerospace experience was in the early days of the Shuttle, and back then there were interfaces that required raw addresses to be propagated from the MDMs into the software build, and raw addresses from the build into external ground- and crew-control systems.
It's now obviously almost 40 years later, and there's plenty of both hardware and software technology that would obviate that kind of thing in a new system. But Atlas V is really a bit more than 20 years old, if you count the design process (where such things are decided), so I'm not sure of the sophistication of the interface.
If you do a maintenance build on the A5 avionics and it moves stuff around in memory a bit, an interface that says "get me the value of the object labelled 'MET #2'" is pretty much immune to all but an actual bug being introduced. On the other hand, a new build when the interface is "get me the 32-bit value that resides at 0x056789ab" requires perfect config control between the A5 avionics team and the Starliner team.
