More information from Jim Bridenstine's (NASA Administrator) twitter[1]:
Update: #Starliner had a Mission Elapsed Time (MET) anomaly causing the spacecraft to believe that it was in an orbital insertion burn, when it was not. More information at 9am ET:
Because #Starliner believed it was in an orbital insertion burn (or that the burn was complete), the dead bands were reduced and the spacecraft burned more fuel than anticipated to maintain precise control. This precluded @Space_Station rendezvous.
We are getting good burns and are elevating the orbit of the spacecraft.
There will be a press conference on NASA TV[0] at 9:30am ET (29 minutes from now)
Also some speculation from Scott Manley[2][3] that the spacecraft may have fired it's engines 90 degrees from prograde during orbital insertion, based on mission control displays seen during the launch livestream
I know people over there. They are struggling but there's still a solid contingent that gives a shit. To spite some missteps they seem to be doing ok at getting young blood in and maintaining a productive culture.
That is a very expensive mistake, but it could have been a lot worse, at least they made it to orbit. The orbit reached is a stable one and if it were a crewed mission at least at this point in time the crew would be fine. If they can't reach the ISS (which is what it looks like right now) they'll have to deorbit a bit sooner, there is a lot of money riding on them making it down in one piece, if they fail at that then you may want to trade in some (more) of your Boeing stock.
It's been a very tough year for Boeing, and SpaceX makes it all seem so easy that you tend to forget this stuff is very hard and that success is not at all guaranteed.
As you said that was a recovered capsule from an ocean landing that they were testing. SpaceX will not be using recovered capsules for crewed missions.
To be fair they have not stated why it exploded. If it was damage during landing or retrieval then oh well. It could be a design flaw.
Edit: It turns out they did explain and I missed that news.
Certainly - there's no reason that system would've been pressurized while in orbit. That won't have prevented NASA from getting mental images of the ISS blowing up, though, and it would still have been a concern for crewed launches where the abort system would have been pressurized; it's good they redesigned to prevent the possibility at all.
There is a big difference in the consequences, but the fact that it was a test does not, of course, mean one can dismiss the question of whether, and how, a significant problem had escaped all efforts to eliminate unnecessary risks up to that point. Once something has reached the point where it is considered nominally ready for use (or has actually been put in service), the failure of a test conducted within operational parameters should be treated as seriously as a failure in actual use.
Not that it shouldn't be, or wasn't, treated seriously. But it was very far from operational parameters. It was a previously flown capsule that had been dunked in sea water. Crew capsules are not re-used.
There's no indication in the post-mortem that the issue had anything to do with reuse or immersion.
> "We believe that we had a liquid slug of the (NTO) in the pressurization system," Koenigsmann said. "When we opened the valves and pressurized the propellant system, we think that this slug was driven back into the check valve. ... That basically destroyed the check valve and caused an explosion."
> Although the OIG report in question never specifically states it, some of the language used to describe Dragon 2’s cargo configuration does seem to imply that Cargo Dragon 2s will predominately (if not exclusively) be derived as slightly-modified Crew Dragon capsules, seemingly indicating that SpaceX’s CRS-2 missions may only ever launch flight-proven Crew Dragon capsules.
That might or might not have been relevant, and the fact that something was changed as a consquence of the investigation argues strongly for the latter.
I do not understand the effort being put into arguing that this failure was largely inconsequential because it was a test. Clearly - and rightly - neither SpaceX nor NASA took it that way.
And yet it's still important to not misstate facts regardless of whether or not they are relevant, because other people will take those supposed facts and apply them in other ways then you did.
And yet it's still important to not merely present facts regardless of whether or not they are relevant, because other people will take those facts and suppose they are relevant.
Note the issue that unites these two statements - it is relevance. A test does not have to be a simulation of actual use to be relevant.
Let me say this in a different way. As soon as you misstate a fact in a public forum where people might not know the truth of the matter, that misstatement becomes relevant to many readers. Because otherwise people will read your supposed fact, assume it is true, and apply it elsewhere.
That doesn't make it necessarily relevant to the original point of whether or not it was an issue that needed to be taken seriously, but that's why I explicitly started my post by stating so.
I honestly can't believe that you're defending a serious misstatement of the conditions of the test on the internet by saying "well it doesn't matter that the premise of my post was wrong". Of course it matters, even if I agree with your conclusion anyways.
The premise of my post is not wrong, because if you read what I actually wrote, you will see that nowhere do I state that this test was conducted entirely as if it was a real manned mission to the ISS - of course, it wasn't, including for all sorts of facts that do not have anything to do with the previous history of the capsule. What I actually set out, in my first post, is a principle for regarding tests as being as significant as real operations, and it so happens that this principle still largely holds even when a test deviates to some extent from a real operation. I did not state this obvious extension because I did not anticipate a pointlessly pedantic response.
Until the failure had been diagnosed, it would have been correct to consider whether the problem was entirely the consequence of the capsule's previous history, but by now, we are all - even you - agreed that the test did reveal a potentially serious problem that could be fixed. It turns out, fortunately, that tests do not have to be equivalent to live operations to be useful, because relevance does not depend on them being so (as this case demonstrates.)
Undeniably, this does not say that this test was conducted entirely within operational parameters - as I wrote before, it sets out a principle for taking tests seriously. It also, intentionally, suggests that you consider this test as being close enough to be relevant, and you have offered no argument against that.
> significant problem had escaped all efforts to eliminate unnecessary risks up to that point.
This test was part of the process of identifying and eliminating those risks.
There is no difference between a failure during a test and a failure during operation, in terms of identifying needed changes in space craft design.
There is a difference when it comes to evaluating the design and testing process of the company. SpaceX seems to be very good at balancing moving quickly with design, then testing safely, using those test to find weaknesses and learning from their failures to iterate rapidly.
Despite some early failures, it seems SpaceX is rapidly on its way to having the best launch safety record in the industry.
All I am saying is that by the time you are flying the thing, you should have high confidence in it. A failure at that point should lead to a serious reevaluation of that confidence, regardless of whether the failure occurs on a test or an operation (the exception being those tests that are to destruction, or at least well outside the operational envelope, and only then if the failure occurs at about the point you expect, or beyond it.)
> All I am saying is that by the time you are flying the thing, you should have high confidence in it.
It seems like there is a balance between the level of confidence you achieve prior to a flight test, the costs of a failed test, and the speed at which you can implement and iterate designs.
> A failure at that point should lead to a serious reevaluation of that confidence,
If, as in this case, the failure is due to non-considered risk, you certainly want to make changes to the assumptions you make during the design process in the future (in additional to the changes you make in your current design.)
I don't think you need to generally question your confidence in your components that have not only passed all their operational tests, but have been used successfully to complete operational missions.
Only because they were shaking it to bits while trying to light the emergency abort engines as a shakedown test for Nasa, reusing a capsule they had used before.
Well yeah, but at the same time, you want anything that could possibly go wrong to go wrong before you finish testing. A test that finds a design flaw is a successful test.
Vibration testing is common practice on accepting a particular engine design. All engines will typically perform this type of test and be expected to pass.
I agree if you mean the difference between the MET error and the vibration failure. I tend to disagree if you mean the vibration failure mode in a test stand vs. a potential vibration failure mode on a mission.
The capsule blew up while firing the abort motors. If the abort motors fired while the capsule was anywhere near the ISS, it wouldn't have mattered if it exploded or not.
> The capsule blew up while firing the abort motors.
To be clear, it blew up when pressurizing those motors' systems, not during firing. As you note, that makes it unlikely to have happened in orbit, but it's still a major concern for future crew - it's a step that'd happen in every launch. Hence the redesign.
To be clear, "pressurizing" is part of the "firing" process. It occurs ~200ms prior to ignition. It is not a step that would happen during every launch. It would only happen if the SuperDracos were fired (in an abort scenario).
This was a serious flaw in a critical system, and the redesign was very important. It also advances the state of the art in engineering in these sorts of systems... the failure that took place was something that no one considered possible (specifically the Ti/NTO reaction).
I was just responding to the fact that you mentioned the capsule had visited the ISS, which is totally irrelevant to the failure.
No doubt this will still advance the state of the art in aerospace systems, but there's some old data by Boeing and NASA that seem to indicate some potential compatibility issues with Ti in the presence of a strong oxidizer.
On December 29, 1953, a technician at Edwards Air Force Base was examining a set of titanium samples immersed in RFNA, when, absolutely without warning, one or more of them detonated, smashing him up, spraying him with acid and flying glass, and filling the room with NO2. The technician, probably fortunately for him, died of asphyxiation without regaining consciousness.
There was a terrific brouhaha, as might be expected, and JPL undertook to find out what had happened. J. B. Rittenhouse and his associates tracked the facts down, and by 1956 they were fairly clear. Initial intergranular corrosion produced a fine black powder of (mainly) metallic titanium. And this, when wet with nitric acid, was as sensitive as nitroglycerine or mercury fulminate. (The driving reaction, of course, was the formation of TiO2.) Not all titanium alloys behaved this way, but enough did to keep the metal in the doghouse for years, as far as the propellant people were concerned.
Different oxidizer from SpaceX, but still useful as a data point.
Not sure SpaceX makes it seem easy. To me it's more like they get a free pass for a lot of failures because people like what they're doing and think the company is cool.
The story "cowboy innovates rapidly, kills someone" sells a lot easier than "old crusty firm attempts to take zero risks, floats on past success, still kills someone"
One thing I learned from a recent Everyday Astronaut video is that NASA has a long history of trying to calculate the chances of failure for a vehicle before it has ever flown. They got it wrong with the space shuttle for example. And this method requires a lot of extra factors of safety and expensive parts. An alternate method is to test in flight, and this is what SpaceX does. Boeing uses the other method. So Boeing systems are supposed to be relatively failure free, while some SpaceX systems may at some point be expected to fail. Of course SpaceX is supposed to have their testing done before humans get onboard, so those systems should still be reliable.
But a big difference is Boeing tests on the ground and SpaceX tests in flight.
They're also a very young company in the space, with a fraction of the experience that the incumbents have. It's more understandable to make mistakes when you're that new to such a complex industry.
Is there any real US experience left with creating manned capsules for space? I would guess there are no Apollo engineers available, and Shuttle engineers for the same had a very different configuration. For general space experience, also the ability to maintain controlled processes for existing space vehicles is not a fully overlapping skill set with developing new space vehicles. In a way, every company is starting from new using historical data.
People don't even remember the SpaceX failures. SpaceX CRS-1's secondary payload was left in an unstable orbit and ORBCOMM's $10 million prototype burned up in Earth's atmosphere about 4 days later. CRS-2 had an issue involving the RCS thruster, but was able to recover. CRS-7's launch vehicle catastrophically failed, the cargo capsule ejected, but its parachutes didn't deploy (had it been a crewed mission, the astronauts would have died). The $200 million Amos-6 satellite was lost in a launch pad explosion and Musk, being the paranoid weirdo he is, initially blamed it on imaginary United Launch Alliance saboteurs—for which there was an investigation by the Air Force’s 45th Space Wing at Musk's request.
Notably, ULA has a nearly perfect record (they've never lost a vehicle, only one or two payloads didn't reach the correct orbit) and ULA has launched nearly twice as many times compared to SpaceX. While the SpaceX's record is very bad by modern standards.
> Both SpaceX and Orbcomm were aware, prior to the mission, of the high risk that the secondary payload satellite could remain at the lower altitude of the Dragon insertion orbit, and that was a risk that Orbcomm agreed to take given the dramatically lower cost of launch for a secondary payload.
As for this...
> CRS-7's launch vehicle catastrophically failed, the cargo capsule ejected, but its parachutes didn't deploy (had it been a crewed mission, the astronauts would have died)
Had it been a crewed mission, the parachutes would've been active. It's not standard practice to have a escape rockets or armed parachutes on ascent for cargo flights, SpaceX or otherwise. Standards are different for crewed flights.
For CRS-1 there was a risk of a lower altitude obit, that wasn't the outcome—they lost the satellite.
For CRS-7 Wikipedia says "SpaceX officials stated that it could have been recovered if the parachutes had deployed, but the software in the capsule did not include any provisions for parachute deployment in this situation."
> For CRS-1 there was a risk of a lower altitude obit, that wasn't the outcome—they lost the satellite.
No, that was the outcome. The lower orbit has much more atmospheric drag, resulting in deorbit within a few days. SpaceX and Orbcomm both knew this was a possibility. From Wikipedia: "Both SpaceX and Orbcomm were aware, prior to the mission, of the high risk that the secondary payload satellite could remain at the lower altitude of the Dragon insertion orbit, and that was a risk that Orbcomm agreed to take given the dramatically lower cost of launch for a secondary payload."
Your Boeing cost prediction don't include the possibility of catastrophic RUD during reentry (still 2 days out). At that point does NASA cancel starliner?
There is simply no way that the US government will let Boeing fail as a company. Even if this thing blows up, I think it will still be funded, especially given their commercial airline troubles.
SpaceX is basically the Google of aerospace at this time, Boeing is like IBM. Their interview process is incredibly rigorous while Boeing's is a joke. I've worked with people from both places (former aerospace engineer), their respective workers are not in the same league.
What? What do you base that on? Banks may be too big to fail because single bank can affect millions of lives, I doubt you can say the same about one of few plane competitors. Otherwise we could apply your logic to every fortune 500 corp.
Boeing makes and maintains the Pentagon's ICBMs, tankers, fighters, bombers, satellites, launch vehicles, etc. It's one of the country's most critical national security assets.
I don't think it's that crazy actually. In some far future scenario one could see Boeing going into bankruptcy protection (a lot would need to happen to get to that point), after which the healthy parts like the defense related divisions could be spun off into a new company.
I don't think it's likely, but it doesn't seem impossible.
It’s very likely the government would be fine with wiping out common shareholders, issuing a government loan, and then installing some oversight. Too big to fail doesn’t mean shareholders don’t get screwed.
The price being high on the market means that none of these issues are a real threat to the company.
That'd be a different part of the government involved. I doubt the military is as concerned about common shareholders as the Treasury was in 2008. The US would never allow the capability to build Boeing's military aircraft to be lost. That could be done during bankruptcy rather than before though.
Boeing's military aircraft, with the exception of the V-22 with Bell, are primarily warmed over versions of the old McDonnell Douglas designs, still produced in the same plants.
The military could very cleanly nationalise the Defense division and leave Boeing Commercial to flap in the wind.
The only complications would be the P-8 and KC-46 which use Boeing civil airframes.
Boeing is directly necessary for US military defense. Arguably, failing banks is a political issue not military. If the banks go down and people panic or riot, politicians may be voted out or have to pass measures to fund the banks but the military will still need planes.
Well, they let Lehman fail, and AIG, Fannie/Freddie shareholders were mostly wiped out, so... That's hundreds of billions of shareholders being wiped out.
The post Lehman fallout is why I don't expect Boeing to get the "go ahead, declare bankruptcy" approach from the government. Post-Lehman, we got TARP to prevent more of them.
I've little doubt we'd get a Troubled Boeing Relief Program if a Boeing bankruptcy was looming.
Net cost of TARP is said to be something like $32 billion. If that's true, then complaining about it seems laughable in the face of people basically ignoring trillion dollar deficits.
To be fair, Boeing is developing a new capsule, while SpaceX is making Dragon 2, drawing on the legacy of Dragon 1, which they were awarded at least $1B for.
This sort of issue would have shown up on the first Dragon 1 flight if SpaceX had it.
The total amounts awarded to each company still differ by nearly $2 billion. I cannot imagine how much more Boeing would cost if they weren’t forced to compete with SpaceX.
I wonder how much further along SpaceX might be if they were able to ripoff NASA and the federal government the same way Boeing is able to.
Still, even if it borked this is still a fairly monumental step in the development. Getting stuff into space isn't all that easy and there's a lot that can go wrong even if you successfully launch something, I'm sure they'll gather a ton of actionable data and fix it in the next attempt.
The first thing I thought when I saw those photos was — large format Kodachrome. Those clearly have the color pallet of Kodachrome and many of those old WWII era propaganda color photos were shot on 4x5.
NASA isn't in the same category as the other companies you mentioned. It's a government (and, to an extent, regulatory) space agency which contracts those other companies to build its projects.
I feel like this idea of creating a private market for space exploration is a huge waste of public money. NASA worked better when produced everything in-house.
I am not American, so: not my money, not my country. I have no say in it... But I wonder if I am the only one to think like that.
>NASA worked better when produced everything in-house.
No way. NASA is subject to the political whims of two branches of government. The executive branch is looking for short term wins and the legislative branch is looking for jobs in their districts.
The private market has introduced great innovations that are significantly driving down the cost of going to space.
Nonsense. The private companies have wildly different decision making processes and incentives and have done things very differently from NASA.
SpaceX is landing and reusing rockets every month, resulting in much lower launch costs, and you're saying the only difference is where the money is going? Get out of here.
> NASA worked better when produced everything in-house.
I believe NASA has never produced everything in-house. They don't build (or even design, as far as I can tell) launch vehicles, spacecraft, EVA suits, computers etc. They come up with requirements and contract private companies to build hardware (and software, for that matter) meeting those requirements. For an example, see how the Apollo Lunar Module came to be [1].
> NASA worked better when produced everything in-house.
NASA doesn't run a rocket factory. It used to be that NASA specified and ordered hardware from contractors then integrated and operated it in house. The space shuttle orbiter was built by Rockwell (now ~Boeing), the external tank by Martin Marietta (now Lockheed Martin), the SRBs by Morton Thiokol (now ATK).
Commercial cargo and commercial crew change this model to NASA specifying and ordering missions or mission capabilities. This affords the vendor more autonomy in how they choose to solve problems, and NASA's still in the loop to sign off on their solutions. In principle, this approach contains cost overruns, since NASA pays only for the deliverable. What it doesn't contain are schedule overruns…
> creating a private market for space exploration is a huge waste of public money
Others have commented on how NASA has never built very much in-house.
But I'll go broader. American technological leadership, in space and other fields, goes back to its private contracting heritage. Contractors competed to develop tech. They then had an incentive to find other uses for that tech, thereby proliferating its benefits into the broader economy.
It's not a coincidence that while most countries have a tepid public space program, America has multiple launch vehicles under development for a diversity of purposes.
You are conflating quite a few different things here and leaving out some key players at the same time.
NASA & ESA are not the same as Boeing & Airbus
Launch vehicles are not the same field as "space travel"
Spinning up entities like JPL is a non trivial matter in either civilian or commercial domains.
Spreading the engineering challenges across a wider array of organisations would not expedite their solution imho. Just thin out the available resources.
There are already other options, if NASA had chosen to fund them -- Sierra Nevada put together a fairly strong bid for their DreamChaser lifting body, which is still being funded as one of the next-generation commercial ISS cargo transports.
There have been two public full scale tests of this spacecraft. A pad abort test (launch the abort system from the ground to make sure it can escape a launch vehicle failure) and this.
In the pad abort test a parachute failed, this wouldn't have been a deadly failure since the remaining parachutes are sufficient, but it is pretty damn concerning.
Now this test suffered a major failure too.
This does not bode well for the reliability of this vehicle.
Because not getting to the ISS would mean a mission failure of a much worse kind than temporarily being stuck in the wrong orbit. If astronauts were on board (which they are not, I know) that would mean no relief and a complete loss of mission, if they could make it to the ISS then that would be 100% mission success in spite of being stuck for a while.
The specific claim seems to be that if the capsule were manned, the crew could have intervened, when the problem was first detected, to correct the error. With no crew aboard, ground control was unable to make the correction because, at precisely that time, the vehicle was in a dead zone between communications satellites.
It is not entirely clear to me whether this would have been the chosen course of action had it been manned, or whether it is merely being presented in support of the statement that it would not have created a dangerous situation.
Would be interesting to see a comparison of project management approaches at SpaceX vs. Boeing. I suspect that Boeing has far more antiquated, politically motivated cruft scattered throughout.
I was just about to write something similar - the reason nasa projects fail is because they refuse to allow for iteration. Every flight from the first flight must be flawless. Look at Spacex ... they iterate just fine for their own private fleet but the minute they start work with nasa they grind to a a slow pace.. boeing, bless their poor hearts, grew up on the nasa pork so they aren’t structured to iterate if they wanted to... like a declawed cat who has never been outdoors pretending to be fierce, they thrive on the impression that what they are doing is space exploration. And now when it’s starting to become real... oops...
> the reason nasa projects fail is because they refuse to allow for iteration
Could this be a relic of the era when we needed people in the spacecraft? As far as I'm aware, SpaceX has never had manned flights - a catastrophic explosion is momentary bad press, but they can continue on. Every time someone died in NASA it was a real tragedy. Plus every NASA launchpad explosion is more obviously "wasted" tax payer money.
I think everyone would agree that manned flights should be as thoroughly tested as possible. Although SpaceX has never had manned flights, they do dock with the ISS, a failure of which could have very real consequences including possible loss of life.
The belief that an iterative, agile approach is too "fast and loose" for complex engineering projects has been throughly debunked, but for some reason continues to pervade.
Your comment comes across as if it's a forgone conclusion that agile development is adequate but it seems like there is still plenty of debate on this in terms of safety-critical systems.
"The quality control mechanisms supported by current agile processes (e.g., informal reviews, pair-programming) have not been proven to be adequate to assure users that the product is safe. In fact there is some doubt these techniques alone will be sufficient. Formal specification, rigorous test coverage, and other formal analysis and evaluation techniques included in software engineering approaches provide better, but also more expensive, mechanisms to tackle the development of safety- or business- critical software" [1]
SpaceX has shown quality control issues on their hardware processes in the past, which, from the outside looking in seems like they should have been caught.[2] I wonder if the fact that they are a relatively young organization is why these processes were lacking to begin with. It seems to be the nature of the learning process that as the 'unknown unknowns' are uncovered, processes will become more robust (and possibly cumbersome) by extension. The real question is whether they should have been unknown to begin with. I also wonder if they will start to look less like the agile upstart as they create more mature processes.
Reference 1 is nearly 20 years old, much has changed in those 20 years.
Reference 2 is non sequitur; nobody is suggesting that there are zero errors/failures in agile, simply that Boeing may benefit from taking a more agile approach.
I agree that the attitude regarding agile development has changed, but the point from Ref. 1 was that the topic isn't nearly as settled yet as your comment might lead one to believe. There is still considerable debate within the aerospace industry on how and when agile development is appropriate. I would be legitimately interested if you have relevant references to successful applications of agile methodologies to safety-critical human rated space software development.
Sorry if I wasn't clear enough on the point of Ref. 2. The reason that was brought up was the issue found was related to supplier quality. The fact that these checks were not in place is a bit surprising from a quality perspective and SpaceX indicated they will include additional quality oversight in the future.[1] I.e., through failures, they are adding additional processes that move them away from being an agile organization and closer towards the bureaucratic processes they are often contrasted against.
"SpaceX will implement additional hardware quality audits throughout the vehicle to further ensure all parts received perform as expected per their certification documentation."[1]
I'm familiar with the agile approach, but what you quoted isn't unique to agile; it can be found in any quality program that implements continuous improvement. It also slightly begs the question by using the agile manifesto as a reference to justify agile development.
What I am hoping to find is more concrete examples of successful application of agile processes to safety-critical software. For example, how can user stories be used in lieu of a traditional software requirements specification and still effectively capture all the necessary safety requirements (including those the customer may be unaware of).
I think we will really see how this plays out with starship. Just look at the number of iterations it’s gone through. I personally prefer to plan everything and think of every iteration and eventuality. But Whenever I do post mortems in my projects, I find that the most rapid learning came from putting on my knee pads and getting under the frame and getting grease under my nails and dust in my hair. Sorry for the analogies!
Oh it’s definitely because of this... that’s why I think Spacex was right to pursue a path where each flight gets considerably cheaper with reuse and to prove the platform with cargo rather than pursue space tourism. Now they have a flight proven business and can work on the hard stuff. Each time a broken timer doesn’t work for spacex, as long as the rocket is recovered, they basically lose the cost of the capsule and the fuel. Every time Boeing fails, it’s what? $100 million (I don’t have a source for that)... spacex could have iterated already and have a man in space but nasa is worried about protecting Boeing’s ego that they are slowing spacex’s cadence... maybe that’s not fair... I get that nasa also is not an agile org so it needs time to absorb and analyze findings too. Regardless, at this point, I think it’s clear that nasa is propping up a failed program at Boeing and the sooner they deal with it and SLS, the sooner we can get on to actual space exploration.
The cost of a new-built capsule is likely more than the cost of the rocket, for both companies. Though Boeing may not be out that money in this case -- the CST-100 is supposed to be reusable, so there's at least the prospect of relaunching the same capsule if this one lands safely (and they will try to get it back on the ground even if ISS rendezvous is no longer possible).
As for SpaceX's cadence, one of those NASA-mandated tests, which was thought to be low-risk beforehand, did blow up the capsule. That sort of thing makes it a little awkward to be critical of the test requirements afterward. And while I am also very much a fan of the "cheap iterations" approach up to a point, it's less appropriate once people are on the craft and their lives are at stake.
My understanding is once the capsules splash down that’s it for the capsule as a passenger ferry. Does Boeing get to reuse theirs? I lost track of the final resolution on the stand test but if I recall I don’t think that was intended to be low risk..they shook it until something broke if I recall. But even so wouldn’t you count that as an iteration?
Boeing does get to reuse theirs. SpaceX is ultimately planning to reuse them as well, but is planning a new capsule each flight for the initial contract while negotiating recertification requirements with NASA. (That's what they did for cargo dragon as well -- they're reusing those now, but it took a while.)
From 1958, when McDonnell (now Boeing) built the Mercury spacecraft, through 1969, when Apollo 11 (first stage and lunar rover built by Boeing, 3rd stage by McDonnel) landed on the Moon, Boeing rapidly iterated and was an 'outdoor cat'. NASA moved pretty quickly back then, too.
They've just gotten comfortable indoors, growing fat, lazy, and old in the decades since then.
I know your comment is the typical explanation, but to play devil's advocate, it may just be that as organizations mature they move away from "innovation" and towards "maintenance". There's a perspective that that may not exactly be a bad thing. [1]
I've heard people say SpaceX looks very much like NASA during the Apollo days, including the average age being in the mid-20s in the control rooms. Contrast that with today where NASA's average age is north of 50. What I think will be interesting is if SpaceX maintains this over the coming decades or if they will become more bureaucratic as the organization ages.
I mean, they regularly build robots, strap them on huge rockets, shoot them 300,000,000 miles away to mars, land them without a scratch, and drive them around for years. That’s awesome.
In fairness, the SpaceX people likely also get the pleasure of getting to work a few extra hours each day in order to ensure they complete their sprint. So that's nice...
Good point - I would guess that Boeing's process is a much longer and more extensive waterfall (i.e. one major iteration on a large scale), whereas smaller companies like SpaceX go through the waterfall for multiple shorter iterations. There are advantages and disadvantages to both approaches, I assume.
I worked at Lockheed Martin as a Systems Engineer for a few years. Everything we worked on as a project was waterfall. We did annual training using the methodology and did exercises around it as well. I think it's rather commonplace for defense contractors and wouldn't be surprised if this were still the case for Boeing.
This line would be funnier if you dropped the word engine. I am not aware of another Boeing product where an incorrect sensor caused an "engine" stall.
I think it's possible that they were in a state of stall for an infinitely small moment of time before they were obliterated. They definitely came to a halt, which is another meaning for stall.
It does not matter one bit if they technically stalled for 20 milliseconds between making initial ground contact and disintegrating into 10000+ pieces.
The root cause is kinetic energy -- slamming into the ground at 600mph nearly vertical.
Infinitely small is the same as nonexistent, and stalls don’t mean what you think they do on jet engines. Comparing a jet engine stall to an automotive stall is the easiest and most obvious tell that someone is speaking from aviation inexperience. Stalls definitely, categorically, absolutely did not occur in the contextual incidents at any time including impact. Source: ATP with 17,000 hours on a similar type, and I’ve flown the accident configuration.
I swear this site is nothing more than a competition to be most correct (and outside of JavaScript arguments people never are, amusingly), because this entire thread is so pointless as to be a detriment to all involved, me included. In what other context would it even be remotely useful to argue about this, aside from the investigation? Why do HN readers think the ability to write software makes them coherent debaters on every topic imaginable, including extremely complicated propulsion systems they’ve probably never touched? Aviation discussion particularly worries me here because in the past I’ve seen some doubting of those who have held the wreckage in their hands by those whose primary competency is Rails and React, commenting safely from several thousand nautical miles away from the investigation.
I look forward to the societal impacts of upvoting and karma being studied more deeply in time, because it is quite a rot on conversation and drives people into hopelessly pedantic arguments like this one that are literally a drain on human productivity and the limited time you have on this planet. There were over 300 deceased pax aboard the aircraft you casually referred to as “obliterated” in an off topic thread about Starliner, too, but keep driving to the bottom of this argument, for sure. I’m sure they and their families will appreciate you getting it right.
Actually asking, what are you trying to say? I'm interpreting this as airplanes don't have engines, but a jet turbine is still an engine, so you must mean something else?
I think it's a nitpick that an aerodynamic stall (plane not going forward fast enough for wings to generate lift) should not be conflated with an engine stall (engine ceases to burn/spin/propel)
If we're in nitpick land, it truly is important (especially in that 737 case) to remember that stalls on wings has nothing to do with speed, and everything to do with angle of attack (the angle between the wing and the apparent wind).
Now, to be fair, going faster DOES create apparent wind coming from the front, so it decreases your angle of attack, but that's it.
(the sensor that failed on the 737s was the angle of attack indicator, trying to estimate if the wing was going to stall).
Well, both are basically the same physical phenomenon: too much adverse pressure gradient leading to flow detachment from the airfoil, either the wing airfoil or the compressor blade airfoil.
Boeing's explanation is that the flight automation software runs on some sort of "timer" and the timing apparently wasn't configured correctly, so Starliner thought it was at a different part of the mission and did the wrong burns.
Astonishing to me they make it sound like it runs like an independent stopwatch and not kept in sync with the actual IRL mission parameters in a more direct/continuous way. They're talking about the automation handover between the launch vehicle to the spacecraft, and on Starliner "clearly the time got messed up" ... "the spacecraft was not on the timer we expected it to be on"
Running it on a timer actually works quite well. I don't know how this particular system actually works, but for example the Saturn V launch vehicle handled the initial navigation for several minutes from takeoff by executing previously calculated commands based on launch time, weather conditions etc.
Also, if I have understood things correctly, the lunar lander used a timer based approach to keep the rotation of the vehicle aligned with the surface of the moon as it orbited.
Since the orbital dynamics are very well understood and there really isn't anything that can affect the motion of the spacecraft other than engine burns, there doesn't seem to be any good reason to make it more complicated.
That is true. In the Saturn V case, the guidance computer checked the actual location of the spacecraft and issued corrections that had accumulated due to precisely that.
They could do it but the pilots wanted something to do so they got to fly manually. The Russians did unmanned launch and landing with their space shuttle Buran.
Onnplanet earth, where those things are launched their is an atmosphere with wind. That wind impacts where exactly the rocket leaves the atmosphere and deploys the space ship.
> This is like saying that because the airplane crashed because the wing
> was incorrectly designed and popped off, everyone should fly biplanes...
We do that. Not with the wings, but with the engines. When jetliner engines were less reliable, we required 3 or more engines on flights that included long sections without passing near an airport (mostly transoceanic flights). Now that some engines are more reliable, we have ETOPS certifications for jetliners using two high-reliablility engines. And yes, there still are two, because no matter how reliable the engines may be, one _may_ fail.
Let's compare the number of instances a timer has caused an issue and the number of instances it hasn't to determine the actual rate before we make a broad assumption about a field we have no experience in due to a single test case, yes?
Yeah I’m a programmer like most of us here and I’ve seen timers abused quite a lot. They sometimes are appropriate, but more often, they are good examples of an antipattern.
The wording “it would seem” should have tipped you off that no assumptions are being made, but I guess it didn’t work.
And even if we were to make a comparison as you suggest and derive some ratio, that’s not super useful without comparing it to the ratio for some alternative approach that does not use timers.
> Since the orbital dynamics are very well understood and there really isn't anything that can affect the motion of the spacecraft other than engine burns
This is wrong.
1) Atmospheric drag (unless you're in really high orbits)
2) Wind
3) Uneven gravitational field. Our planet is not a perfect sphere. The moon is even less so.
4) Solar pressure (though very minor and kinda evens out in orbit).
Which of these can't you calculate ahead of the launch? Numbers 1, 3, and 4 seem like you could calculate it ahead of time. And maybe number 2 as well, if you do it relatively close to launch time.
The unevenness of the gravitational field on Earth is for the most part ignorable. It isn't like maneuvers are precise enough that one could account for it in the calculations anyway.
Space is empty enough and engines imprecise enough that for orbital stuff you have enough margins to correctly predict and plan a trajectory ahead of time, and just do correction burns later if necessary.
On the Moon the gravitational field is indeed uneven enough to matter, but exactly one orbiter really cares about it (LRO iirc has a specific orbit where the unevenness mostly cancels out), most simply rely on occasional station keeping burns.
> flight automation software runs on some sort of "timer"
Interesting, this might explain the failure to land the rover (vikram) on the dark side of the moon by India's recent moon mission.
For example, what if the altitude assumed by the timer is off by a few kilometers, and it starts operating in a manner which is for landing within few meters.
Landings are not generally done like that though. A landing would be basically impossible without active guidance, due to it being a far more precise maneuver than in-orbit maneuvers.
>Flight controllers recognised the problem but were unable to intervene quickly enough because the capsule was passing between satellite links.
I imagine the reason timers are used is this right here. We don't have complete coverage of the earth for satellite control, so there needs to be a timer running for when it can't phone home to stay synchronized.
This is a very disappointing approach I see on HN. Armchair analysis based on sparse information in the article assuming all kinds of things about the avionics, space hardware and rocket physics, condemning an entire team of software engineers that are working on this issue.
Think about this - if you're one of those software engineers and you read some random person on forums criticizing your work without context or thorough understanding, how would you feel?
I love HN for insight and intellectual debate, this kind of analysis does not add any insight - it is flat out dismissing and condescending.
Edit: Also, this behavior against Boeing is unwarranted because it has bias of 737 MAX issues. Completely different team, completely different problem.
Yes. For the most part, software engineering is "easy". Find and apply appropriate data structure and algorithm, done. Managing a large legacy codebase and dealing with the soft factors is the hardest part of the job.
This leads to a phenomenon where software engineers tend to come up with "one weird trick to solve the space shuttle, NASA hates him". And it's always specifically software engineers.
Generally, most people are just as competent at their job as you are at yours. If the obvious solution is not being used, there is usually a very good reason why. A lot of fields have problems that are hard for reasons of physics or other things that are not trivially gone around, and the solution is not one software engineer swooping in with a great idea that totally revolutionizes avionics.
(sometimes of course it is social factors, same as software engineering. The best way is too expensive, or management is making bad decisions, etc)
The jump to simple solutions in hindsight bothers me. Especially with software in complex safety-critical systems it's often incredibly hard to capture all the permutations that can lead to a failure mode.
I wouldn't doubt most programmers could do an failure mode effects analysis on the software and figure out they need to mitigate an event where the timer fails to sync. But how many would also capture how to mitigate that sync failure at the precise time the system lost satellite comm? Probably a heck of a lot less.
Now multiply that by the total number of software failure modes (including those latent ones we just get lucky with) and see how many get captured. There's a reason why software in these types of systems is incredibly hard to test.
If you are actually on the team, you shouldn't be reading HN or any other random internet forum to try and get accurate feedback on your work in the first place.
That's besides the point - I was just making a remark that how would they "feel". Not saying at all about whether they should looking around on the internet for feedback.
Culture is culture. The 737 Max issues relate to the 787 battery issues relate to this. Is the company run by safety-first oriented aeronautical engineers or not.
>Think about this - if you're one of those software engineers and you read some random person on forums criticizing your work without context or thorough understanding, how would you feel?
Who gives a shit how he feels? He works at a company that builds death traps, and someone at that company has built one himself. People like this should feel overpowering shame and contemplate the poor life choices that brought them to this terrible place.
Boeing is a great argument for the corporate death penalty. Its stock price should go to zero, and its assets divided between its creditors and the military pieces nationalized.
I would wager that even if you find the one guy/girl who made this timer error, the decision to not use other sensors, other failsafes was probably made by a higher-up or a team.
It's usually driven by system safety analysis criteria. E.g., if a timer failure is categorized as "catastrophic" it may be required to have X amount of redundancy. The amount of redundancy defined by 'X' may be driven by customer (i.e. NASA) requirements.
Agree. HN is getting full of people with some serious chips on their shoulder. Any article with the words "Amazon", "Boeing", "Google", or "Facebook" in it will be flooded with, to be blunt, a bunch of garbage posts. Not a good insightful, intellectual discussion. Just people with massive chips on their shoulders flooding the comments with noise.
>this behavior against Boeing is unwarranted because it has bias of 737 MAX issues. Completely different team, completely different problem.
Wrong. Do you somehow thing there's a different management team running these parts of the company? There's only one CEO at Boeing, it's only one company. And culture starts at the top.
Questioning Boeing's competence here is entirely warranted when the company has already PROVEN that it is happy to put profits ahead of safety.
That's internet in a nutshell, and HN is not that different despite pretensions to the contrary. What partly redeems it is the better than even chance that in posts with technical subjects, someone informed and/or competent will appear and write something worthy. You learn to filter out the rest.
"Completely different team, completely different problem"
It...seems sort of similar to me, based on the article I read. It's not similar at all in the consequences, because of the context of the flight. But in the way things went wrong.
A question that I have unanswered is, Boeing was reported as saying that if there were astronauts they would be "safe"...but would it be possible to retrieve them?
The problem is that there is ample press and experts who have scrutinized the 737-MAX issues for over 8 months now - there were multiple systematic/organizational issues and oversights all over the place - that should be duly criticized and it was, but let's learn about this other issue in a completely different division (Space), take hints and jump to conclusions about their incompetence. This is immature, condescending and disrespectful of the engineers that worked on making this happen.
SHIT happens in space flight all the time. The rate at which shit happens in space is on a few orders of magnitude different than shit that happens in commercial aerospace. Ask how many times SpaceX failed to do what they do today and it will fail more times in future, no doubt.
I also understand the company culture point - yea, company culture probably isnt the best at Boeing but they've done many many things right in past decades. They're a huge company with a lot of talented engineers (and a lot of bozos). Their CEO is a complete asshat and I am sure people inside Boeing talk about it.
I just think that there is unnecessary scrunity without data to say definitively what happened.
> Mr Bridenstine suggested that had astronauts been aboard they could have been able to correct the fault and successfully get the craft to the space station.
Its really unfortunate to hear this news as its not easy to gt these things off the ground. (pun very much intended) Hopefully it doesn't take too long for another attempt if any.
That is somewhat hard to believe. Boeing/NASA have everything to gain by showing that they really had that capability and if they don't then I'm going to assume that they can't.
It was half in jest. I worked on a cubesat in college, with the long term goal of the project to build networks of service satellites (imaging, repair, repositions, refuel...).
I'd love to chat about the idea in more depth with you, it's defiantly plausible and with the increased rate of launch it could be a great business.
If you're interested in sucking on the government teat, email DARPA-SN-19-29@darpa.mil and tell them you're interested in the on-orbit satellite servicing competition. The deadline might've already passed to enter, but it's worth a shot.
Interesting it doesn't mention the test dummy was modeled after Rosie the Riveter, and they are all feminist power for the flight, going so far as to pose for this photo:
255 comments
[ 2.8 ms ] story [ 281 ms ] threadUpdate: #Starliner had a Mission Elapsed Time (MET) anomaly causing the spacecraft to believe that it was in an orbital insertion burn, when it was not. More information at 9am ET:
Because #Starliner believed it was in an orbital insertion burn (or that the burn was complete), the dead bands were reduced and the spacecraft burned more fuel than anticipated to maintain precise control. This precluded @Space_Station rendezvous.
We are getting good burns and are elevating the orbit of the spacecraft.
There will be a press conference on NASA TV[0] at 9:30am ET (29 minutes from now)
Also some speculation from Scott Manley[2][3] that the spacecraft may have fired it's engines 90 degrees from prograde during orbital insertion, based on mission control displays seen during the launch livestream
[0] https://www.nasa.gov/live/ [1] https://twitter.com/JimBridenstine/status/120802259102746215... [2] https://twitter.com/DJSnM [3] https://twitter.com/DJSnM/status/1208006636746330120
Edit: looks like Tory Bruno (ULA CEO) has confirmed that Atlas and Centaur performed well [0]
[0] https://twitter.com/planet4589/status/1208035453850587136
http://www-users.math.umn.edu/~arnold//disasters/patriot.htm...
It's been a very tough year for Boeing, and SpaceX makes it all seem so easy that you tend to forget this stuff is very hard and that success is not at all guaranteed.
To be fair, their version of this capsule blew up rather dramatically.
https://www.youtube.com/watch?v=xe4ee56aHSg
After that exact capsule had visited the ISS, incidentally, which must've caused a little butt-clenching at NASA.
Is this a covertly taken video? Why so low quality?
https://www.space.com/spacex-crew-dragon-explosion-nasa-memo...
To be fair they have not stated why it exploded. If it was damage during landing or retrieval then oh well. It could be a design flaw.
Edit: It turns out they did explain and I missed that news.
Yes, they have.
https://www.cbsnews.com/news/spacex-explosion-destroyed-crew...
They redesigned the capsule to not need the valve.
They actually did explain:
https://www.businessinsider.com/spacex-crew-dragon-explosion...
> "We believe that we had a liquid slug of the (NTO) in the pressurization system," Koenigsmann said. "When we opened the valves and pressurized the propellant system, we think that this slug was driven back into the check valve. ... That basically destroyed the check valve and caused an explosion."
Hence the redesign.
There's also been discussion of reusing Crew Dragon on unmanned CRS missions. https://www.teslarati.com/spacex-no-crew-dragon-spaceship-re...
> Although the OIG report in question never specifically states it, some of the language used to describe Dragon 2’s cargo configuration does seem to imply that Cargo Dragon 2s will predominately (if not exclusively) be derived as slightly-modified Crew Dragon capsules, seemingly indicating that SpaceX’s CRS-2 missions may only ever launch flight-proven Crew Dragon capsules.
I do not understand the effort being put into arguing that this failure was largely inconsequential because it was a test. Clearly - and rightly - neither SpaceX nor NASA took it that way.
That's not what I'm attempting to argue... and why my post starts with a disclaimer that I'm not trying to argue that.
I just think it's important to keep the facts straight.
Note the issue that unites these two statements - it is relevance. A test does not have to be a simulation of actual use to be relevant.
That doesn't make it necessarily relevant to the original point of whether or not it was an issue that needed to be taken seriously, but that's why I explicitly started my post by stating so.
I honestly can't believe that you're defending a serious misstatement of the conditions of the test on the internet by saying "well it doesn't matter that the premise of my post was wrong". Of course it matters, even if I agree with your conclusion anyways.
The capsule blew up. True.
The capsule blew up after already having visited the ISS. Also true.
Wasn't much more to my post.
> the failure of a test conducted within operational parameters should be treated as seriously as a failure in actual use.
Everything before the "should be".
Until the failure had been diagnosed, it would have been correct to consider whether the problem was entirely the consequence of the capsule's previous history, but by now, we are all - even you - agreed that the test did reveal a potentially serious problem that could be fixed. It turns out, fortunately, that tests do not have to be equivalent to live operations to be useful, because relevance does not depend on them being so (as this case demonstrates.)
The premise, that the test was conducted within operational parameters, is not true.
This test was part of the process of identifying and eliminating those risks.
There is no difference between a failure during a test and a failure during operation, in terms of identifying needed changes in space craft design.
There is a difference when it comes to evaluating the design and testing process of the company. SpaceX seems to be very good at balancing moving quickly with design, then testing safely, using those test to find weaknesses and learning from their failures to iterate rapidly.
Despite some early failures, it seems SpaceX is rapidly on its way to having the best launch safety record in the industry.
I agree that SpaceX is looking very competent.
It seems like there is a balance between the level of confidence you achieve prior to a flight test, the costs of a failed test, and the speed at which you can implement and iterate designs.
> A failure at that point should lead to a serious reevaluation of that confidence,
If, as in this case, the failure is due to non-considered risk, you certainly want to make changes to the assumptions you make during the design process in the future (in additional to the changes you make in your current design.)
I don't think you need to generally question your confidence in your components that have not only passed all their operational tests, but have been used successfully to complete operational missions.
So I don't think that's at all a fair comparison.
That they wound up redesigned indicates NASA and SpaceX agree.
To be clear, it blew up when pressurizing those motors' systems, not during firing. As you note, that makes it unlikely to have happened in orbit, but it's still a major concern for future crew - it's a step that'd happen in every launch. Hence the redesign.
This was a serious flaw in a critical system, and the redesign was very important. It also advances the state of the art in engineering in these sorts of systems... the failure that took place was something that no one considered possible (specifically the Ti/NTO reaction).
I was just responding to the fact that you mentioned the capsule had visited the ISS, which is totally irrelevant to the failure.
See PDF pg. 66 (not report pagination) https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/197200...
See PDF pg.11 https://apps.dtic.mil/dtic/tr/fulltext/u2/866010.pdf
On December 29, 1953, a technician at Edwards Air Force Base was examining a set of titanium samples immersed in RFNA, when, absolutely without warning, one or more of them detonated, smashing him up, spraying him with acid and flying glass, and filling the room with NO2. The technician, probably fortunately for him, died of asphyxiation without regaining consciousness.
There was a terrific brouhaha, as might be expected, and JPL undertook to find out what had happened. J. B. Rittenhouse and his associates tracked the facts down, and by 1956 they were fairly clear. Initial intergranular corrosion produced a fine black powder of (mainly) metallic titanium. And this, when wet with nitric acid, was as sensitive as nitroglycerine or mercury fulminate. (The driving reaction, of course, was the formation of TiO2.) Not all titanium alloys behaved this way, but enough did to keep the metal in the doghouse for years, as far as the propellant people were concerned.
Different oxidizer from SpaceX, but still useful as a data point.
But a big difference is Boeing tests on the ground and SpaceX tests in flight.
Notably, ULA has a nearly perfect record (they've never lost a vehicle, only one or two payloads didn't reach the correct orbit) and ULA has launched nearly twice as many times compared to SpaceX. While the SpaceX's record is very bad by modern standards.
https://en.wikipedia.org/wiki/SpaceX_CRS-1#Secondary_payload
> Both SpaceX and Orbcomm were aware, prior to the mission, of the high risk that the secondary payload satellite could remain at the lower altitude of the Dragon insertion orbit, and that was a risk that Orbcomm agreed to take given the dramatically lower cost of launch for a secondary payload.
As for this...
> CRS-7's launch vehicle catastrophically failed, the cargo capsule ejected, but its parachutes didn't deploy (had it been a crewed mission, the astronauts would have died)
Had it been a crewed mission, the parachutes would've been active. It's not standard practice to have a escape rockets or armed parachutes on ascent for cargo flights, SpaceX or otherwise. Standards are different for crewed flights.
For CRS-7 Wikipedia says "SpaceX officials stated that it could have been recovered if the parachutes had deployed, but the software in the capsule did not include any provisions for parachute deployment in this situation."
No, that was the outcome. The lower orbit has much more atmospheric drag, resulting in deorbit within a few days. SpaceX and Orbcomm both knew this was a possibility. From Wikipedia: "Both SpaceX and Orbcomm were aware, prior to the mission, of the high risk that the secondary payload satellite could remain at the lower altitude of the Dragon insertion orbit, and that was a risk that Orbcomm agreed to take given the dramatically lower cost of launch for a secondary payload."
FTFY
https://spacenews.com/missing-pin-blamed-for-boeing-pad-abor...
It also singlehandedly makes up about a half a percent of GDP. https://www.cnbc.com/2019/03/21/boeings-737-max-could-hit-us...
I don't think it's likely, but it doesn't seem impossible.
The price being high on the market means that none of these issues are a real threat to the company.
Furthermore, the military has not demonstrated much ability to constrain the excesses of the military-industrial complex in any matter.
I doubt that's true.
https://en.wikipedia.org/wiki/Patrick_M._Shanahan
> He previously spent 30 years at Boeing in a variety of roles.
There are plenty of examples of this sort of revolving door between contractors like Boeing and the US government.
The military could very cleanly nationalise the Defense division and leave Boeing Commercial to flap in the wind.
The only complications would be the P-8 and KC-46 which use Boeing civil airframes.
I've little doubt we'd get a Troubled Boeing Relief Program if a Boeing bankruptcy was looming.
I suspect the same would be true with a Boeing bailout, especially if you count the continued employment of the staff at their 8,000+ suppliers.
Am I looking at the wrong stock or something?
https://www.marketwatch.com/investing/stock/ba
https://arstechnica.com/science/2019/11/nasa-report-finds-bo...
This sort of issue would have shown up on the first Dragon 1 flight if SpaceX had it.
I wonder how much further along SpaceX might be if they were able to ripoff NASA and the federal government the same way Boeing is able to.
Still, even if it borked this is still a fairly monumental step in the development. Getting stuff into space isn't all that easy and there's a lot that can go wrong even if you successfully launch something, I'm sure they'll gather a ton of actionable data and fix it in the next attempt.
https://blogs.nasa.gov/commercialcrew/2019/12/20/meet-rosie-...
https://en.wikipedia.org/wiki/Rosie_the_Riveter#/media/File:...
I think they are colorized. Here one comparison of the original [0] (taken in the 30s/40s!) in comparison to the image on Wikipedia [1]
[0] http://loc.gov/pictures/resource/fsac.1a34931/
[1] https://en.wikipedia.org/wiki/Rosie_the_Riveter#/media/File:...
It'll be good for space travel and the space economy.
I am not American, so: not my money, not my country. I have no say in it... But I wonder if I am the only one to think like that.
No way. NASA is subject to the political whims of two branches of government. The executive branch is looking for short term wins and the legislative branch is looking for jobs in their districts.
The private market has introduced great innovations that are significantly driving down the cost of going to space.
The only difference is that public money now is financing private companies...
SpaceX is landing and reusing rockets every month, resulting in much lower launch costs, and you're saying the only difference is where the money is going? Get out of here.
I believe NASA has never produced everything in-house. They don't build (or even design, as far as I can tell) launch vehicles, spacecraft, EVA suits, computers etc. They come up with requirements and contract private companies to build hardware (and software, for that matter) meeting those requirements. For an example, see how the Apollo Lunar Module came to be [1].
[1] https://en.wikipedia.org/wiki/Apollo_Lunar_Module#Contract_l...
NASA doesn't run a rocket factory. It used to be that NASA specified and ordered hardware from contractors then integrated and operated it in house. The space shuttle orbiter was built by Rockwell (now ~Boeing), the external tank by Martin Marietta (now Lockheed Martin), the SRBs by Morton Thiokol (now ATK).
Commercial cargo and commercial crew change this model to NASA specifying and ordering missions or mission capabilities. This affords the vendor more autonomy in how they choose to solve problems, and NASA's still in the loop to sign off on their solutions. In principle, this approach contains cost overruns, since NASA pays only for the deliverable. What it doesn't contain are schedule overruns…
Others have commented on how NASA has never built very much in-house.
But I'll go broader. American technological leadership, in space and other fields, goes back to its private contracting heritage. Contractors competed to develop tech. They then had an incentive to find other uses for that tech, thereby proliferating its benefits into the broader economy.
It's not a coincidence that while most countries have a tepid public space program, America has multiple launch vehicles under development for a diversity of purposes.
NASA & ESA are not the same as Boeing & Airbus
Launch vehicles are not the same field as "space travel"
Spinning up entities like JPL is a non trivial matter in either civilian or commercial domains.
Spreading the engineering challenges across a wider array of organisations would not expedite their solution imho. Just thin out the available resources.
In the pad abort test a parachute failed, this wouldn't have been a deadly failure since the remaining parachutes are sufficient, but it is pretty damn concerning.
Now this test suffered a major failure too.
This does not bode well for the reliability of this vehicle.
It is not entirely clear to me whether this would have been the chosen course of action had it been manned, or whether it is merely being presented in support of the statement that it would not have created a dangerous situation.
Could this be a relic of the era when we needed people in the spacecraft? As far as I'm aware, SpaceX has never had manned flights - a catastrophic explosion is momentary bad press, but they can continue on. Every time someone died in NASA it was a real tragedy. Plus every NASA launchpad explosion is more obviously "wasted" tax payer money.
I think everyone would agree that manned flights should be as thoroughly tested as possible. Although SpaceX has never had manned flights, they do dock with the ISS, a failure of which could have very real consequences including possible loss of life.
The belief that an iterative, agile approach is too "fast and loose" for complex engineering projects has been throughly debunked, but for some reason continues to pervade.
"The quality control mechanisms supported by current agile processes (e.g., informal reviews, pair-programming) have not been proven to be adequate to assure users that the product is safe. In fact there is some doubt these techniques alone will be sufficient. Formal specification, rigorous test coverage, and other formal analysis and evaluation techniques included in software engineering approaches provide better, but also more expensive, mechanisms to tackle the development of safety- or business- critical software" [1]
SpaceX has shown quality control issues on their hardware processes in the past, which, from the outside looking in seems like they should have been caught.[2] I wonder if the fact that they are a relatively young organization is why these processes were lacking to begin with. It seems to be the nature of the learning process that as the 'unknown unknowns' are uncovered, processes will become more robust (and possibly cumbersome) by extension. The real question is whether they should have been unknown to begin with. I also wonder if they will start to look less like the agile upstart as they create more mature processes.
[1] https://arxiv.org/ftp/arxiv/papers/1409/1409.6600.pdf
[2] https://www.wsj.com/articles/structural-failure-likely-cause...
Reference 2 is non sequitur; nobody is suggesting that there are zero errors/failures in agile, simply that Boeing may benefit from taking a more agile approach.
Here's how iteration works: https://www.youtube.com/watch?v=bvim4rsNHkQ
Sorry if I wasn't clear enough on the point of Ref. 2. The reason that was brought up was the issue found was related to supplier quality. The fact that these checks were not in place is a bit surprising from a quality perspective and SpaceX indicated they will include additional quality oversight in the future.[1] I.e., through failures, they are adding additional processes that move them away from being an agile organization and closer towards the bureaucratic processes they are often contrasted against.
"SpaceX will implement additional hardware quality audits throughout the vehicle to further ensure all parts received perform as expected per their certification documentation."[1]
[1]https://www.spacex.com/news/2015/07/20/crs-7-investigation-u...
What I am hoping to find is more concrete examples of successful application of agile processes to safety-critical software. For example, how can user stories be used in lieu of a traditional software requirements specification and still effectively capture all the necessary safety requirements (including those the customer may be unaware of).
As for SpaceX's cadence, one of those NASA-mandated tests, which was thought to be low-risk beforehand, did blow up the capsule. That sort of thing makes it a little awkward to be critical of the test requirements afterward. And while I am also very much a fan of the "cheap iterations" approach up to a point, it's less appropriate once people are on the craft and their lives are at stake.
They've just gotten comfortable indoors, growing fat, lazy, and old in the decades since then.
I've heard people say SpaceX looks very much like NASA during the Apollo days, including the average age being in the mid-20s in the control rooms. Contrast that with today where NASA's average age is north of 50. What I think will be interesting is if SpaceX maintains this over the coming decades or if they will become more bureaucratic as the organization ages.
http://freakonomics.com/podcast/in-praise-of-maintenance/
If that's why they fail, do they regularly succeed in spite of it or also because of it?
It wasn’t the engines (Boeing doesn’t make engines). It was MCAS.
It does not matter one bit if they technically stalled for 20 milliseconds between making initial ground contact and disintegrating into 10000+ pieces.
The root cause is kinetic energy -- slamming into the ground at 600mph nearly vertical.
Everything else is just logical-masturbation.
I swear this site is nothing more than a competition to be most correct (and outside of JavaScript arguments people never are, amusingly), because this entire thread is so pointless as to be a detriment to all involved, me included. In what other context would it even be remotely useful to argue about this, aside from the investigation? Why do HN readers think the ability to write software makes them coherent debaters on every topic imaginable, including extremely complicated propulsion systems they’ve probably never touched? Aviation discussion particularly worries me here because in the past I’ve seen some doubting of those who have held the wreckage in their hands by those whose primary competency is Rails and React, commenting safely from several thousand nautical miles away from the investigation.
I look forward to the societal impacts of upvoting and karma being studied more deeply in time, because it is quite a rot on conversation and drives people into hopelessly pedantic arguments like this one that are literally a drain on human productivity and the limited time you have on this planet. There were over 300 deceased pax aboard the aircraft you casually referred to as “obliterated” in an off topic thread about Starliner, too, but keep driving to the bottom of this argument, for sure. I’m sure they and their families will appreciate you getting it right.
Now, to be fair, going faster DOES create apparent wind coming from the front, so it decreases your angle of attack, but that's it.
(the sensor that failed on the 737s was the angle of attack indicator, trying to estimate if the wing was going to stall).
Astonishing to me they make it sound like it runs like an independent stopwatch and not kept in sync with the actual IRL mission parameters in a more direct/continuous way. They're talking about the automation handover between the launch vehicle to the spacecraft, and on Starliner "clearly the time got messed up" ... "the spacecraft was not on the timer we expected it to be on"
Also, if I have understood things correctly, the lunar lander used a timer based approach to keep the rotation of the vehicle aligned with the surface of the moon as it orbited.
Since the orbital dynamics are very well understood and there really isn't anything that can affect the motion of the spacecraft other than engine burns, there doesn't seem to be any good reason to make it more complicated.
But many things can go slightly wrong when firing all engines fighting your way up the atmosphere.
This is like saying that because the airplane crashed because the wing was incorrectly designed and popped off, everyone should fly biplanes...
We do that. Not with the wings, but with the engines. When jetliner engines were less reliable, we required 3 or more engines on flights that included long sections without passing near an airport (mostly transoceanic flights). Now that some engines are more reliable, we have ETOPS certifications for jetliners using two high-reliablility engines. And yes, there still are two, because no matter how reliable the engines may be, one _may_ fail.
What is backing up that CST-100 timer?
https://en.wikipedia.org/wiki/ETOPS
It would seem we have an existence proof now saying that the above statement is incorrect.
The wording “it would seem” should have tipped you off that no assumptions are being made, but I guess it didn’t work.
And even if we were to make a comparison as you suggest and derive some ratio, that’s not super useful without comparing it to the ratio for some alternative approach that does not use timers.
This is wrong.
1) Atmospheric drag (unless you're in really high orbits)
2) Wind
3) Uneven gravitational field. Our planet is not a perfect sphere. The moon is even less so.
4) Solar pressure (though very minor and kinda evens out in orbit).
But regardless, this was a Boeing spacecraft; it wasn't built by NASA (NASA generally does systems engineering; contractors build things like this).
Space is empty enough and engines imprecise enough that for orbital stuff you have enough margins to correctly predict and plan a trajectory ahead of time, and just do correction burns later if necessary.
On the Moon the gravitational field is indeed uneven enough to matter, but exactly one orbiter really cares about it (LRO iirc has a specific orbit where the unevenness mostly cancels out), most simply rely on occasional station keeping burns.
Interesting, this might explain the failure to land the rover (vikram) on the dark side of the moon by India's recent moon mission.
For example, what if the altitude assumed by the timer is off by a few kilometers, and it starts operating in a manner which is for landing within few meters.
I imagine the reason timers are used is this right here. We don't have complete coverage of the earth for satellite control, so there needs to be a timer running for when it can't phone home to stay synchronized.
Think about this - if you're one of those software engineers and you read some random person on forums criticizing your work without context or thorough understanding, how would you feel?
I love HN for insight and intellectual debate, this kind of analysis does not add any insight - it is flat out dismissing and condescending.
Edit: Also, this behavior against Boeing is unwarranted because it has bias of 737 MAX issues. Completely different team, completely different problem.
This leads to a phenomenon where software engineers tend to come up with "one weird trick to solve the space shuttle, NASA hates him". And it's always specifically software engineers.
Generally, most people are just as competent at their job as you are at yours. If the obvious solution is not being used, there is usually a very good reason why. A lot of fields have problems that are hard for reasons of physics or other things that are not trivially gone around, and the solution is not one software engineer swooping in with a great idea that totally revolutionizes avionics.
(sometimes of course it is social factors, same as software engineering. The best way is too expensive, or management is making bad decisions, etc)
I wouldn't doubt most programmers could do an failure mode effects analysis on the software and figure out they need to mitigate an event where the timer fails to sync. But how many would also capture how to mitigate that sync failure at the precise time the system lost satellite comm? Probably a heck of a lot less.
Now multiply that by the total number of software failure modes (including those latent ones we just get lucky with) and see how many get captured. There's a reason why software in these types of systems is incredibly hard to test.
Who gives a shit how he feels? He works at a company that builds death traps, and someone at that company has built one himself. People like this should feel overpowering shame and contemplate the poor life choices that brought them to this terrible place.
Boeing is a great argument for the corporate death penalty. Its stock price should go to zero, and its assets divided between its creditors and the military pieces nationalized.
Wrong. Do you somehow thing there's a different management team running these parts of the company? There's only one CEO at Boeing, it's only one company. And culture starts at the top.
Questioning Boeing's competence here is entirely warranted when the company has already PROVEN that it is happy to put profits ahead of safety.
That's internet in a nutshell, and HN is not that different despite pretensions to the contrary. What partly redeems it is the better than even chance that in posts with technical subjects, someone informed and/or competent will appear and write something worthy. You learn to filter out the rest.
It...seems sort of similar to me, based on the article I read. It's not similar at all in the consequences, because of the context of the flight. But in the way things went wrong.
A question that I have unanswered is, Boeing was reported as saying that if there were astronauts they would be "safe"...but would it be possible to retrieve them?
SHIT happens in space flight all the time. The rate at which shit happens in space is on a few orders of magnitude different than shit that happens in commercial aerospace. Ask how many times SpaceX failed to do what they do today and it will fail more times in future, no doubt.
I also understand the company culture point - yea, company culture probably isnt the best at Boeing but they've done many many things right in past decades. They're a huge company with a lot of talented engineers (and a lot of bozos). Their CEO is a complete asshat and I am sure people inside Boeing talk about it.
I just think that there is unnecessary scrunity without data to say definitively what happened.
Its really unfortunate to hear this news as its not easy to gt these things off the ground. (pun very much intended) Hopefully it doesn't take too long for another attempt if any.
I'd love to chat about the idea in more depth with you, it's defiantly plausible and with the increased rate of launch it could be a great business.
https://twitter.com/BoeingSpace/status/1207977494277738496?r...