""While this anomaly was corrected in flight, if it had gone uncorrected it would have led to erroneous thruster firing and uncontrolled motion during SM separation for deorbit, with the potential for catastrophic spacecraft failure," Hill said during the meeting."
"The flight was also memorable for its dramatic re-entry. The craft's service module did not separate, so it entered the atmosphere nose-first, leaving cosmonaut Boris Volynov hanging by his restraining straps. As the craft aerobraked, the atmosphere burned through the module. But the craft righted itself before the escape hatch was burned through."
This actually happened three times so far with the Soyuz (in all cases without the loss of crew):
"An incomplete separation between the Service and Reentry Modules led to emergency situations during Soyuz 5, Soyuz TMA-10 and Soyuz TMA-11, which led to an incorrect reentry orientation (crew ingress hatch first)."
One would kinda expect that past crewed vehicle emergencies would be studied in detail when designing a new one & that the developers would make extra sure they can't reasonably happen with their design.
Given commercial pressures would a Boeing reentry vehicle be over designed to such a extent that on such a failure (failure to separate, entering with the wrong attitude ?correct term?) result in "...the craft righted itself before the escape hatch was burned through"?
I would assume it would work the same as with the soyuz, provided that the service module separates/explodes before the capsule reentering the wrong way is irrecoverably damaged.
Basically, all space capsules have their of gravity placed in such a way that they will automatically orient themselves heat shield forward once they encounter the atmosphere. So once the service module is gone, it should flip into the correct orientation just by physics alone.
(BTW, this is the same reason why the Crew Dragon spacecraft keeps it's aft section "ring" attached during a launch escape, where it's super draco thrusters drag it to a safe distance from a failing launcher.
The aft ring prevents the capsule from trying to flip over during the abort. Then once in safe distance from the vapor & debris cloud that used to be the launcher, the aft section is jettisoned and the capsule again automatically re-orients itself heat shield forward.)
I think who you're replying to is implying the escape hatch would have been cheaper if it wouldn't last long enough before burn through during improper re-entry
"Given the potential for systemic issues at Boeing, I would also note that NASA has decided to proceed with an organizational safety assessment with Boeing as they previously conducted with SpaceX"
Well, their CEO also doesn’t go on podcasts and smoke pot. Not that I think that’s necessarily a better or worse sign that SpaceX is or is not safe than a CEO drinking moderately in public, but we are prudish about these things in the States.
> According to the source, Boeing patched a software code error just two hours before the vehicle reentered Earth's atmosphere. Had the error not been caught, the source said, proper thrusters would not open during the reentry process, and the vehicle would have been lost.
Uh, that's extremely concerning for a CREWED capsule.
It depends on if the crew would have been able to control those thrusters themselves. Obviously you want the entire system to be autonomous enough that no crew interaction is required but things do happen and the crew needs to be able to act and fix the problem if capsule can't do it nor the ground. When the Starliner started a burn at the wrong time, a crew would have been able to stop it and prevent the loss of fuel. I wonder if this re-entry thruster issue was a result of the earlier thruster issue (or a result of the troubleshooting of it).
There are uncrewed test flights for a reason. You can't always simulate every possible failure mode. Things fail on the ground that wouldn't be possible during normal operation and vice versa.
The "crew would fix it" argument is a very very bad one. Many spacecraft maneuvers need to be very precise in both pointing and direction. Something computers are very good at, humans less so.
Also, the crew would first have to know something wrong is going on either based on activity happening that was not planned previously or unexpected data on flight instruments. But guess what is driving those instruments in a modern crewed space vehicle - also computers and software. That software might be faulty as well or even displaying the same wrong data the automated control software is acting upon.
In such a case the crew might not even notice something is wrong until the craft is on a wrong and potentially even unrecoverable trajectory once ground radar notices something is wrong.
As for the crew taking over thtuster control during a reentry - sorry, if you space capsule is trying to kill you that hard, something is wrong.
At that point in time, the capsule is hurtling through the atmosphere protected only by its from ablative shield. The thrusters are used to shift the center of gravity a bit, to give the capsule some lift, offsetting some of the g forces due to the rapid deceleration. This is called "lifting reentry".
This all needs to be very very precise & based on up to date sensor data, as the whole capsule is not covered by the heat shield and if you change the center of gravity too much, you might expose unprotected parts of it to the hot plasma.
This is not really a good environment for a crew member to take over - not only are you under couple g's of deceleration but any mistake will kill you all. But hey, no pressure!
BTW, the Soyuz capsule has a backup mode available in case it's reentry control thrusters fail, where the capsule just follows an unguided ballistic reentry. This is much harder on the crew (due to no lift compensating for some of the deceleration), but survivable & has been used a couple times during various emergencies.
Im not disagreeing with you, I suppose, but we did do this before with a lot less sophisticated systems and a lot more manual control. It stands to reason that, given proper training, a pilot of one of these spacecraft could identify a problem and switch to manual.
Sure, but that's different from a simpler spacecraft that simply does not have such automated systems, affecting crew training accordingly.
Having one that has sophisticated automation which you need to constantly monitor in case it tries to kill you due to a simple programming error is not really comparable I'm afraid.
> “Boeing is not going to do an in-flight abort test,” said Jon Cowart, deputy manager of the mission management office for NASA’s commercial crew program, before the pad abort test. “They’re just going to do the ground one. They think that they can get enough data and then extrapolate that out, with good analytical techniques that we’ve endorsed. They will go and do it in that particular way, versus SpaceX, which is going to do both.
> Finally, before the meeting ended, the chair of the safety panel, Patricia Sanders, noted yet another ongoing evaluation of Boeing. "Given the potential for systemic issues at Boeing, I would also note that NASA has decided to proceed with an organizational safety assessment with Boeing as they previously conducted with SpaceX," she said.
Wouldn’t like to be the guy pushing an update to a crewed capsule just before re-entry. I stress out enough about pushing code as it is. But then I wouldn’t like to be the guy who left an error in the code to begin with.
If the schedule called for simulations to be run in parallel with the live test, then it's an expected outcome. It should be _expected_ that every test will find a problem. Since this was uncrewed, there was no risk (other than to the uncompleted tests possibly requiring a second flight) to running them in parallel and porting across fixes for any problems that were found.
It was a schedule compression attempt with a cost of second test flight risk if it failed.
Boeing took the "we'll do very rigorous engineering up front and prove everything on paper" approach, where SpaceX took the "we'll prove it works by actually launching it" approach (which isn't to say SpaceX isn't operating with engineering rigor).
In theory Boeing ran all their simulations over the past couple years, and this flight should have just been a formality. As it turns out, Boeing is running into a lot of issues when they actually test their hardware.
The problem with simulations and paperwork with high tech engineering is you need enough competent, independent reviewers that understand how the whole system works together.
That sort of thing is rarely organized. So we test it instead.
This is likely an oversimplification. There are multiple organizations, even within Boeing Defense & Space, that write their own flight software. All stovepiped and largely working in parallel. This doesn't even include the commercial folks, infamous for the 737 Max. My understanding is that the St. Louis teams are better regarded, and the folks that worked on DARPA HACMS deserve some credit, but they seem to be outliers. Boeing's culture doesn't seem to prioritize modern software development methods or software rigor on the whole. Functional testing should be the last layer of bug-hunting techniques, not the first or primary. The issue seen on their capsule didn't surprise me at all. Other BDS software groups use utterly outdated software development methods and we should all be a little bit worried.
Obviously it's a simplification; comparing and contrasting the approaches of SpaceX and Boeing would require several walls of text...
At the core of the issue though, the process that SpaceX pitched to NASA (and NASA approved) involved quite a bit of actual hardware testing. Boeing's plan (also approved by NASA) relied much more heavily on simulation, modelling, and other sorts of process validation. For instance, Boeing did not perform an in-flight abort.
It kind-of depends on what sort of issue you're finding in your test. Complex systems like spacecraft often have unexpected interaction effects which only testing can reveal. I would call these the 'good' kind of test learnings - ones that an army of great engineers wouldn't be able to predict.
This is editorializing but it looks like Boeing didn't uncover very complicated interactions - they failed at a more basic level of competency - timer synchronization for the launch issue and then a major software bug for an important orbital maneuver. Those sorts of issues really should be sorted out on the ground using hardware simulators. Furthermore, the timer synchronization failure prevented testing of the docking hardware, further delaying the overall program.
For a human rated vehicle, personally I think you should have at least one full-up, fully nominal test before you send anyone along for the ride.
I think we already do — there have been roughly 15 satellites etc. launched for every human who has ever reached earth orbit over the entire history of human spaceflight.
You are right some people find it fun to go to dangerous places, I assume. Think about the crew of StarTrek and of course Buzz Lightyear. Personally I would rather send someone else to space than go there myself :-)
> Makes me wonder why put all this effort to make space-travel safe for crews
Would you want to board that capsule yourself, otherwise?
> Why not focus on remotely controlled or AI autonomous vehicles instead?
Buzzwords doesn't make something more reliable/less error prone. You really think that by throwing in something like AI, which can fail in unexpected ways, be a good idea?
So we know there were catastrophic bugs in the 737 Max, they've found additional bugs that haven't been catastrophic yet and now we hear that the Starliner also has software bugs. I'm going to order a copy of "The Mythical Man-Month" for Boeing ... they need to get way back to the basics.
"Boeing was an early Agile adopter in 2008 surpassing its rival, Airbus, in 2012 by deploying a newly renovated 737 Max 8 faster to market.
[...]
The 2008 article Boeing Frontiers- Goin’ Agile by Doug Cantwell from Boeing describes how Boeing, in partnership with Lockheed Martin, created an Agile lab to move changes to the aircraft to market it faster, cutting down flight test times from months to days.
"
I'd hope that it takes more than 2 months for specs at Boeing. No, we don't write the specs that long, if any. I mean that would be so w-word. In our case while usually almost everybody is on the same page that legs should be attached lower and hands - higher, the actual attachment points and number of the legs, hands, etc. may be pretty fluid through the iterations, and especially the things like number and topology of digits or the shape, number and location of eyes and other sensors.
Having worked at Boeing, I can tell you their specs take way longer than two months to write. That's a good thing.
What's the point of delivering this type of software piecemeal? A new airliner takes 10 years or so to produce. There's no value in shipping half an airplane.
"Individuals and Interaction" over "Process and Tools" doesn't seem like a great idea when developing software that handles life or death scenarios. Boeing, being the finatialized zombie company that they are now though have probably run some economic analysis and determined the optomal time to test / cost of life ratio. They must have determined that the cost of adequately testing their software is waaaaay more expensive than losing an astronaut here and there or some plebian passengers.
I have respect for the software developers who write code where human lives are at risk. I don't think I would sleep well if a bug of mine could create a catastrophic event like that. If I fuckup completely, the only thing lost is money.
Every extra finance-guy in the team means an engineer gets squeezed out. Eventually, there aren't enough engineers to make the team effective. Eventually, there is a disaster because the finance-guys don't have the engineering smarts to recognise failure.
What I would like to know is what the software bug was. Unfortunately the article does not say it, and I am sure no information online exists about this.
On a certain blog that is completely outside acceptable standards for wrongthink and political correctness, a very popular topic of late is why NASA seems to have it in for Elon Musk Personally and SpaceX generally. The commonly stated reasons, and I will be paraphrasing and transliterating freely, are: HR culture defining administration wide objectives and methods and reasoning, professional embarrassment over languishing reputation, gross incompetence, turf defense of budget and status, and a desire to stay firmly planted on Terra while being lauded for dreaming of the stars.
I am always skeptical of any argument that is unfamiliar, but more and more it does appear that NASA has lost its way. The shuttle was an obvious mistake in retrospect; there may even be some credibility to the obscure theory that NASA only did it to further separate themselves from DoD. I think NASA has become a political creature that is less concerned with science and more concerned with SCIENCE™. If this is the case, they will fight tooth and nail against any expansion of manned space exploration (because it will be both private and military in nature), the will fight against innovation that doesn't spring from their own workshop(s), and they will use Cape Canaveral (and their heritage facilities/infrastructure) as a way to bully "adversaries" into submission.
I hope this isn't the case, and if it is, I hope they can reverse whatever practices and policies that have led us to where we are. As it stands though, it appears NASA is more like OSHA then it is like its historical instance.
NASA has always been a political creature, but its mission has changed over the years. Its original mission was to beat the USSR into space. Its new mission is to funnel money to key congressional districts. But it has always been political. Science was always a facade.
Source: I worked for NASA for 15 years (1988-2000, 2001-2004).
The saddest thing about NASA is that the remarkable engineering and scientific capability it possesses... is managed by NASA. It's a great example of one of the most profoundly dysfunctional bureaucracies within the U.S. Government.
It is important as a community that we are aware of the criteria, both claimed and actual, which guide the moderation of our community. Statements like this give people like me an opportunity to research and learn more about the decision making of the mods.
I'm confused by what you mean. NASA has provided SpaceX with lots of expertise and assistance. And you are aware that Starliner is a Boeing vehicle, not SpaceX?
> NASA has provided SpaceX with lots of expertise and assistance.
Can you provide a link about that? I'm aware about SpaceX-NASA cooperation in debugging SpaceX disasters and also financial assistance from NASA on various stages of SpaceX evolution, but would like to learn about substantial involvement of NASA into important technical design and development processes in SpaceX.
"In a salient departure from traditional engine design, NASA and its business partners have adapted commercial, off-the-shelf technologies and common manufacturing methods to develop the Fastrac engine. Significant involvement by small business has aided in broadening the competition and producing lower cost hardware.
For example, Barber-Nichols, Inc. of Arvada, Colo., worked alongside Marshall engineers to design and manufacture the turbopump. The Colorado-based company is experienced in building turbomachinery for the automotive industry and chemical plants, and not traditionally associated with the aerospace industry. The company helped design a turbopump for the Fastrac engine that can be built easily using commercial manufacturing techniques."
Sounds like NASA itself took help from the industry then.
"The SpaceX turbopump was an entirely new, clean sheet design contracted to Barber-Nichols, Inc. in 2002 who performed all design, engineering analysis, and construction; the company had previously worked on turbopumps for the RS-88 (Bantam) and NASA Fastrac engine programs."
Turbopump is often the most complex part of the engine; doing it from scratch raises doubts how much the engine was derived.
I don't think NASA helped to SpaceX that much before Falcon-1 reached the orbit.
After Congress pulled critical funding for a good and actually cheap in use Shuttle, DoD poured money with caveat of requirements that killed shuttle economy long term, many of the requirements never being executed (like polar orbits from Vandenberg)
I guess some things just never get old, citing from https://en.wikipedia.org/wiki/Soyuz_5 :
"The flight was also memorable for its dramatic re-entry. The craft's service module did not separate, so it entered the atmosphere nose-first, leaving cosmonaut Boris Volynov hanging by his restraining straps. As the craft aerobraked, the atmosphere burned through the module. But the craft righted itself before the escape hatch was burned through."
This actually happened three times so far with the Soyuz (in all cases without the loss of crew):
"An incomplete separation between the Service and Reentry Modules led to emergency situations during Soyuz 5, Soyuz TMA-10 and Soyuz TMA-11, which led to an incorrect reentry orientation (crew ingress hatch first)."
(from https://en.wikipedia.org/wiki/Soyuz_(spacecraft)#Service_mod...)
One would kinda expect that past crewed vehicle emergencies would be studied in detail when designing a new one & that the developers would make extra sure they can't reasonably happen with their design.