SpaceX Falcon 9/Dragon CRS-2 SpX-2 MISSION GENERAL DISCUSSION

[Ben the Space Brit]

Yeah, that engine anomaly has really turned into a schedule-brake hasn't it? ULA are having to reschedule too because of the RL-10 problem on the GPS launch.

It might really be a good idea to scrap the last v.1.0 flight and carry out the v.1.1 modifications now.  I would argue that there is no longer any schedule benefit to using v.1.0 for SpX-2.  If they do so, they will have to wait  out an indeterminate period to clear the last v.1.0 and then another delay to modify pad 40 for the v.1.1 which will only mean more delays.  Moving right over to the new version might let them claw back a few months.

[mlindner]

Yeah, that engine anomaly has really turned into a schedule-brake hasn't it? ULA are having to reschedule too because of the RL-10 problem on the GPS launch.

It might really be a good idea to scrap the last v.1.0 flight and carry out the v.1.1 modifications now.  I would argue that there is no longer any schedule benefit to using v.1.0 for SpX-2.  If they do so, they will have to wait  out an indeterminate period to clear the last v.1.0 and then another delay to modify pad 40 for the v.1.1 which will only mean more delays.  Moving right over to the new version might let them claw back a few months.

Except they've already built the hardware. It was almost ready for shipping to the cape, remember? I doubt they're going to just dump the cost of building a full Falcon 9 v1.0.

[ugordan]

It might really be a good idea to scrap the last v.1.0 flight and carry out the v.1.1 modifications now.  I would argue that there is no longer any schedule benefit to using v.1.0 for SpX-2.

What makes you think the first F9 v1.1 flight hardware is even remotely close to its acceptance tests to warrant confidence that this switch would do anything but move the schedule even further to the right?

One engine anomaly does not all of a sudden imply v1.0 is complete crap and that the next one would fail as well, just like people were panicking after the recent Progress launch failure, like it somehow increased the odds of the next vehicle failing as well.

[woods170]

One engine anomaly does not all of a sudden imply v1.0 is complete crap and that the next one would fail as well, just like people were panicking after the recent Progress launch failure, like it somehow increased the odds of the next vehicle failing as well.

Exactly!

[Ben the Space Brit]

This has nothing to do with confidence in v.1.0 and everything to do with their schedule and backlog.  SpaceX is a commercial company and they can't just sit on the ground for six months of next year just to get one flight off.  If they do, their commercial customers, who are going to be their real life-blood, will start falling away to more reliable and faster-moving competitors.

NASA obviously have no problem waiting; the ISS doesn't have anything remotely resembling a supplies crisis.  However, in the case of a commercial satellite, every extra month on the ground is another month the owner/operator isn't using it to generate revenue.  They can't wait too long lest the company fail.  If they lose customers and deposits, they lose money they need for operations and development of future spacecraft like Dragonrider.

Switching to v.1.1 (although as ugordan rightly points out this is a risky technical choice) would at least enable them to reduce the time SLC-40 is out of use next year.  In the end, it is a commercial decision about what is in the company's best interests.

[subzero788]

I think it's a bit early for this kind of talk. We don't even know the exact nature of the failure yet, and what remedies (if any) will be required.

[woods170]

This has nothing to do with confidence in v.1.0 and everything to do with their schedule and backlog.  SpaceX is a commercial company and they can't just sit on the ground for six months of next year just to get one flight off.  If they do, their commercial customers, who are going to be their real life-blood, will start falling away to more reliable and faster-moving competitors.

You paint a much too pessimistic picture. ILS lost only a few customers when Proton failed on a number of missions and had several stand-downs. The majority stayed.
ArianeSpace lost only a few customers after the two flight-failures and associated stand-downs. The majority of their customers stayed.
SpaceX will be no different. They might loose a few customers but the majority will stay committed.
Most customers for launch services are seasoned in the business of spaceflight and are all too aware of the possibility of launch failures and the associated fall-out.
Delays in launching the next flight, even delays of many months, only rarely result in the customers running off to a competitor.

[padrat]

1.1 mods are already underway at the pad, ones that won't prevent launching the last 1.0. So they are already getting a head start on them.

[MP99]

1.1 mods are already underway at the pad, ones that won't prevent launching the last 1.0. So they are already getting a head start on them.

Padrat's back in the saddle again! Thanks for the update.

cheers, Martin

[GalacticIntruder]

Update on mission anomalies.

""The mission's Falcon 9 booster suffered an engine failure moments after liftoff from Cape Canaveral, Fla., and investigators from SpaceX and NASA have found "no smoking gun" on the cause of the problem, according to Mike Suffredini, NASA's space station program manager".

http://www.spaceflightnow.com/falcon9/004/121114anomalies/#.UKULvuQ0WSo

The radiation problem is interesting and disconcerting. It looks like they might have to go with rad hardened systems after all. Probably functional at LEO but there is no way in hell of doing Moon and Mars without them. The seawater issue is mind blowing. You splash down in the ocean, you would think watertight would be solved.

ISS is now March, not January.

[Lars_J]

The radiation problem is interesting and disconcerting. It looks like they might have to go with rad hardened systems after all. Probably functional at LEO but there is no way in hell of doing Moon and Mars without them. The seawater issue is mind blowing. You splash down in the ocean, you would think watertight would be solved.

Engineering is not magic - just because you put in precautions against something does not mean that it will be 100% proof against it. You learn and improve by doing. (See the early Shuttle flights and their tile issues for an example)

[yg1968]

Update on mission anomalies.

""The mission's Falcon 9 booster suffered an engine failure moments after liftoff from Cape Canaveral, Fla., and investigators from SpaceX and NASA have found "no smoking gun" on the cause of the problem, according to Mike Suffredini, NASA's space station program manager".

http://www.spaceflightnow.com/falcon9/004/121114anomalies/#.UKULvuQ0WSo

The radiation problem is interesting and disconcerting. It looks like they might have to go with rad hardened systems after all. Probably functional at LEO but there is no way in hell of doing Moon and Mars without them. The seawater issue is mind blowing. You splash down in the ocean, you would think watertight would be solved.

ISS is now March, not January.

From the SFN article:

Suffredini said the timing of SpaceX's next flight to the station was adjusted partly to accommodate a software update aboard the complex planned for early 2013.

[Robotbeat]

The radiation problem is interesting and disconcerting. It looks like they might have to go with rad hardened systems after all. Probably functional at LEO but there is no way in hell of doing Moon and Mars without them. The seawater issue is mind blowing. You splash down in the ocean, you would think watertight would be solved.

Engineering is not magic - just because you put in precautions against something does not mean that it will be 100% proof against it. You learn and improve by doing. (See the early Shuttle flights and their tile issues for an example)

Heck, if you think SpaceX's computer problems were bad... Shuttle had far worse computer problems at times.

[oldAtlas_Eguy]

For discussions on the details of the SpX-1 problems there is more data in the SpX-1 disscussion thread.

From the standpoint of SpX-2 flight having only 2 operable computers was previously deemed a GO situation. Having an additional problem could result in an abort if it happens during ISS approach. So not much is likely to change for SpX-2 in regards to avionics and radiation upset events and how failures due to them are handled. Some procedures may be changed but that is unknown.

BTW DragonRider is to have 4 computers so that 2 failed computers still leaves an operable system of 2 computers to execute the needed actions whatever they are. The solution for Cargo Dragon may be to just go to the 4 computer configuration with some key parts rad hardend, such as GPS and IMU's.

[Zed_Noir]

Would having more than 4 computers on future Dragons & DragonRiders be practical?

[mlindner]

Would having more than 4 computers on future Dragons & DragonRiders be practical?

Law of diminishing returns applies here. If your expected use scenario does not see you losing more than 2 computers in a single flight then adding more computers doesn't help anything and only adds weight. More so every computer you add adds to the complexity of the hardware which in and of itself add additional failure modes. This was the major problem with clustering engines as a single failure could cause others to fail (say shrapnel).

[cleonard]

Would having more than 4 computers on future Dragons & DragonRiders be practical?

Law of diminishing returns applies here. If your expected use scenario does not see you losing more than 2 computers in a single flight then adding more computers doesn't help anything and only adds weight. More so every computer you add adds to the complexity of the hardware which in and of itself add additional failure modes. This was the major problem with clustering engines as a single failure could cause others to fail (say shrapnel).

Adding another computer wouldn't be simple as it might sound.  The "real" solution would be a hardened computer, but that's no simple task either.  Things are usually tightly packed on systems like the Dragon, but if there is any space at all some more shielding might be the easiest way to better reliability. 

[Zed_Noir]

Would having more than 4 computers on future Dragons & DragonRiders be practical?

Law of diminishing returns applies here. If your expected use scenario does not see you losing more than 2 computers in a single flight then adding more computers doesn't help anything and only adds weight. More so every computer you add adds to the complexity of the hardware which in and of itself add additional failure modes. This was the major problem with clustering engines as a single failure could cause others to fail (say shrapnel).

Adding another computer wouldn't be simple as it might sound.  The "real" solution would be a hardened computer, but that's no simple task either.  Things are usually tightly packed on systems like the Dragon, but if there is any space at all some more shielding might be the easiest way to better reliability. 

More shielding won't stop GCR rad damage, unless you are thinking of putting the computer inside a water tank. Also you take a reduction in computational processing power with rad-harden CPU.

If I understand the CRS-1 post-mission report right. The Dragon was one computer failure away from mission abort. So maybe having 5 or 6 disbursed computer units aboard the Dragon /DragonRider might ensure the required minimum of 2 working units for  rendezvous ops with the ISS is available.

[MP99]

Could Dragon add one hardened computer to the three existing non-hardened? Disimilar redundancy, as I believe Shuttle had.

I presume ops would be more restricted if they failed over to the hardened computer, but that migbt be a reasonable trade-off.

cheers, Martin

[corrodedNut]

Redundancy worked as designed this time. Others have speculated that multiple failures would have resulted in an abort. So my "what if..." question is, how does Dragon (or any other berthed VV) abort while berthed to the ISS? Is it just stuck there?