News Here be Dragons: SpaceX reveals manned Dragon design

[kamaz]

Can you schedule a thread in your smartphone with microsecond accuracy? The last time I looked, the only way this works on a Android phone is to have the functions in the kernel and block all other threads for them. No chance to simply let it do multiple tasks at once as demanded and with the accuracy of a real-time operating system.

It's the problem with software, not hardware. QNX works on TI OMAP, which is a typical smartphone chip. RIM even made a QNX-based smartphone once.

Of course, using a smartphone to control a spacecraft would be stupid. However, an ARM-based computer would be able to do it perfectly.

 

[Urwumpe]

Of course, using a smartphone to control a spacecraft would be stupid. However, an ARM-based computer would be able to do it perfectly.

Yes, but only if it also has the suitable interfacing Hardware. You can for example use a simple AT Mega board for controlling a CANAerospace network of sensors and actuators, if the hardware is around.

That's the deal with smartphones. You have more computing power than the whole NASA of 1970 in your hand with it. But 99% of it used for making smooth scrolling animations and other user interface tasks.

 

[kamaz]

Yes, but only if it also has the suitable interfacing Hardware. You can for example use a simple AT Mega board for controlling a CANAerospace network of sensors and actuators, if the hardware is around.

That's the deal with smartphones. You have more computing power than the whole NASA of 1970 in your hand with it. But 99% of it used for making smooth scrolling animations and other user interface tasks.

You're saying like that's a problem. Use a dedicated computer running RTOS to control the spacecraft. Make it talk over Ethernet to an Android tablet providing the user interface. Problem solved.

 

[Urwumpe]

You're saying like that's a problem. Use a dedicated computer running RTOS to control the spacecraft. Make it talk over Ethernet to an Android tablet providing the user interface. Problem solved.

Its not about the feasibility - its just no simple "We just use some tablets from the shelf" job. Actually, you likely have a lot of extra work to do there, as you say.

Also I doubt that most tablets would be suitable for spaceflight. I would trust a plain old Surface RT there, because destroys everything that tries to destroy it...

 

[kamaz]

Its not about the feasibility - its just no simple "We just use some tablets from the shelf" job. Actually, you likely have a lot of extra work to do there, as you say.

Also I doubt that most tablets would be suitable for spaceflight. I would trust a plain old Surface RT there, because destroys everything that tries to destroy it...

I'm not sure what the exact specs for operation in the spacecraft interior are, but my guess is that MIL-SPEC'd (or even automotive) hardware would meet them. MIL-SPEC tablets and touch screens are off-the-shelf (if expensive) products. First things from Google:

http://www.panasonic.com/business/toughpad/us/secure-tablet-specs.asp
http://www.vartechsystems.com/products/DiamondVueXtreme.asp

From the photo of the interior, they only use physical switches for the power distribution system (they could use locking switches on this, though), and the rest is software interface. In a sense, it is logical: the spacecraft is fly-by-wire anyway, so if your flight computer goes down, having physical switches will not help you. You still have to account for your GUI computer going down, but that's trivially done by duplicating it. The upside is that you save a lot of money (and a lot of mass) associated with a traditional switch panel.

Honestly, I'd be worried more about software reliability here. Environmental conditions in space are well understood, and so are hardware testing methodologies.

 

[Urwumpe]

Honestly, I'd be worried more about software reliability here. Environmental conditions in space are well understood, and so are hardware testing methodologies.

Again, to slow things down a bit: Only because we know the environment, that does not mean we know how a hardware will behave after days in that environment. That requires expensive testing.

Also, software has to handle more hardware failures than usual because of it. The Space Shuttle had a few incidents, in which the error correction of the memory failed and the software had to be rebooted. I/O is more complicated than on the ground, because in space, you really will have the thinkable errors, that you usually can ignore as too unlikely to worry.

And only then there is software reliability as well. If a bug in a Samsung phone worries you because it can take months before it is fixed - in space, the software had to work for simply having the chance to bug fix it sometime.

 

[kamaz]

Not sure if this was posted:

Again, to slow things down a bit: Only because we know the environment, that does not mean we know how a hardware will behave after days in that environment. That requires expensive testing.

Again, we're talking pressurized compartment here. If your parts are ever exposed to conditions exceeding MIL-STD-810, then the crew will be already dead.

Equipment conformant to MIL-STD-810 is off-the-shelf.

 

[Urwumpe]

Again, we're talking pressurized compartment here. If your parts are ever exposed to conditions exceeding MIL-STD-810, then the crew will be already dead.

If architects would be building houses like that, the first woodpecker would be a disaster.

Let us expect that depressurization is a potential hazard.

 

[RGClark]

The coding mavens on this forum (even the ones who don't like SpaceX!) should like this quote from the Musk Q&A on the Dragon V2:

Something that's best worth noting is a lot of what is needed on a rocket and spacecraft is actually software. We actually hire a lot of our best software engineers out of the gaming industry. In fact, myself, I started off when I was a kid - in terms of engineering, I wrote games, that was the thing that I did. I think, in gaming, there's a lot of smart engineering talent doing really complex things. In fact, I think a lot of the algorithms involved in a multi-player online game - compared to a lot of the math that's involved there, doing a docking sequence is actually relatively straight forward. I'd encourage people who are in the gaming industry to think about joining SpaceX and creating the next generation of spacecraft and rockets. Also, probably, in the future we'll create, like, droids on the surface of Mars and the Moon to do things like an automated propellant depot and that kind of thing. We sort of need those pieces to have a base on Mars.

Bob Clark

 

[Urwumpe]

I sense danger.

As professional software developer, my perception of it: I worshipped the developers of the ancient age, when I was young and innocent and I still worship them (Especially the people behind Bullfrog, who had been magicians as team).

But I would not trust them to develop a spacecraft software system. First of all, the amount of bugs even in the old and simple games had been huge compared to modern standards in gaming - and modern games are of the same size as the software complex of a spacecraft (which involves space and ground software) - but with about 20 times more bugs than acceptable in spaceflight.

And then, modern games are very little programming today and a huge lot of game design, graphics, audio, you name it. You don't need to develop solutions for technical problems anymore in most cases, only people who develop graphics engines have to look into concepts how to turn theory into reality. And still, you can't use them for the spacecraft - wrong workflow and likely the wrong personality. People who develop huge distributed information systems (which MMORPGS actually are, though at a lower quality standard) are more suited, especially in the financial industry. People who are used to the fact that a single execution of a bug can cause hundreds of millions dollar in damages.

Spacecraft are less about finding new exciting solutions, than about extremely boring, formal, but also very reliable development. Its all about quality. Performance comes second.

If I would set up a team for making spacecraft software, I would maybe only hire one former game developer, if he can think outside the box - but such a person must not be game developer at all. It could even be somebody who has never programmed in his life. And rather invest into QA, software architects and mathematicians, together with a foundation of experienced, reliable developers. Its mostly standard tasks, so better get people who deliver such standard tasks perfectly every day and make reliable time and cost estimates, instead of looking at creative, but buggy and unmanaged solutions.

Also look at the people who developed the Gemini Math Flow... those are wizards. Look at the algorithms, the complex flow charts... and then remember that such a function has to be implemented with maximal 256memory locations for instructions and two registers, and you only have 16 different instructions to do this. The software has not done anything revolutionary. Bigger computers had been calculating such stuff easily twice per second. But finding out which instructions in which order are really needed and which could be left away, how you can form different entry points to make a function cover different tasks... that's cool and elegant.

 

[kamaz]

If architects would be building houses like that, the first woodpecker would be a disaster.

As someone who actually was writing hardware test programs, I'd appreciate if you refrained from making disparaging comments when speaking outside your area of expertise.

Let us expect that depressurization is a potential hazard.

Given that modern electronics does not contain pressurized components, I fail to see how depressurization would affect operation. The only problem I see with operation in vacuum is heat removal. So you'd have to modify the testing program to include operation in full vacuum (instead of at 20'000 feet as usual). This is however not a problem because the equipment which is used for simulating high altitude conditions can produce full vaccuum.

In practical terms, I'd simply purchase equipment already tested to MIL-STD-810 and run additionals tests for exposure to vacuum and ionizing radiation. Neither is particularly difficult.

 

[Thunder Chicken]

In practical terms, I'd simply purchase equipment already tested to MIL-STD-810 and run additionals tests for exposure to vacuum and ionizing radiation. Neither is particularly difficult.

The TESTS are not particularly difficult. Formulating your plan B design and component sourcing when stuff blows up / falls apart after these tests, that is a bit more touchy.

 

[Urwumpe]

As someone who actually was writing hardware test programs, I'd appreciate if you refrained from making disparaging comments when speaking outside your area of expertise.

First of all: I am speaking inside my area of expertise.

Second: If you would be in your area of expertise, you could counter me with neutral arguments and have much better ones than I have. But I only see you attempting an argument by authority on me. Very sovereign. Can't you do better?

And third, to get back to topic: What kind of bad experience in hardware testing causes you to declare hardware safe by declaring that the problematic event simply can't happen. That's what I mean with the woodpecker.

Depressurization in spacecraft is no rare event. It happened only twice in manned spaceflight history, but one of such instances was deadly (Soyuz-11) and the other was a very close call (Mir).

Also, simply reducing the effects of space to thermal control because "space is a vacuum" is no sign of experience in that subject: Any lecture on spaceflight electronics teaches you that there are more reasons to be scared. And the early flights into space had been full of examples why we know that now. Space is not vacuum enough. Air at sea-level is a great isolator. Vacuum is much different, that's how electronic tubes can operate. And the thermosphere is no vacuum at all. Its full of ions and other particles that love to wreck havoc with electronics.

That notebooks are used on the ISS is no reason because the notebooks are extremely space-worthy hardware. They are non-critical hardware and only operated in a very controlled environment. Should they ever get damaged by getting exposed to space, its simply cheaper to throw them into the docked Progress and request new ones from Earth, than to design vacuum-proof notebooks. But the computers that you really need for controlling the space station are space-proofed, these have been designed for operating even in a thermosphere environment.

And to ruin some more illusions here: That consumer electronics cameras work in 40 km altitude is not the same as working in space. I would not bet that they would work after one hour in 120 km altitude.

So please: stick your argument by authority where the sun doesn't shine and get back to solid ground. Should you really be an authority on hardware testing, you can sure do much better than that, don't you agree?

 

[Cosmic Penguin]

In other news....

 

[kamaz]

And third, to get back to topic: What kind of bad experience in hardware testing causes you to declare hardware safe by declaring that the problematic event simply can't happen. That's what I mean with the woodpecker.

It's not whether the event can happen, it's whether the device is spec'd to survive the event. For example, if the cabin is NOT meant to be depressurized, and depressurization would kill the crew, then having a display unit which can survive depressurization is moot. OTOH, if the spec says that the cabin must be able to be depressurized and repressurized, so the crew can do EVAs, then the qualification process of the display should probably include several hundred cycles of depressurization and repressurization, as well as endurance in both vacuum and atmospheric conditions. Of course the latter display will end up being more expensive. Customer specs, customer gets, customer pays.

Also, simply reducing the effects of space to thermal control because "space is a vacuum" is no sign of experience in that subject: Any lecture on spaceflight electronics teaches you that there are more reasons to be scared. And the early flights into space had been full of examples why we know that now. Space is not vacuum enough. Air at sea-level is a great isolator. Vacuum is much different, that's how electronic tubes can operate. And the thermosphere is no vacuum at all. Its full of ions and other particles that love to wreck havoc with electronics.

Fortunately, we have been flying stuff for over 50 years now, so the conditions in space are well understood, the requirements to survive these conditions are known, and the required hardware qualification tests should also be standardized. It naturally follows that you can purchase off-the-shelf stuff, run it through the qualification process and see if it fails. If it fails, then there is a good chance that the manufacturer knows how to fix it.

I'm going to repeat my point -- I'm much more confident in the ability to adapt existing off-the-shelf hardware to spaceflight conditions than I am confident in the ability to develop reliable software, especially one which can handle soft errors caused by GCRs.

 

[Urwumpe]

It's not whether the event can happen, it's whether the device is spec'd to survive the event. For example, if the cabin is NOT meant to be depressurized, and depressurization would kill the crew, then having a display unit which can survive depressurization is moot.

The crew will survive it. SpaceX is looking into getting a supplier for light-weight pressure suits, similar to the ones worn on Soyuz.

You are right, it makes no sense to have hardware surviving the crew (except flight recorders of course ), but still its the wrong thinking for spaceflight: The spaceflight standard is: Everything may fall apart, as long as the humans survive and return to Earth. Destroying hardware during landing is acceptable, if the crew survives.

I am pretty sure that software could be written that way. Especially since we now have programming languages for exactly such quality standards (for example Ada in its strictest form). It is just no easy way to write software. 95% of the work will not involve programming, but documentation, design and testing.


Also, GCRs are the least big problem there, especially since the majority of the ionizing radiation in LEO comes from the Van Allen Belts and the sun. The composition of the atmosphere around a spacecraft is much more annoying. Or charges building up on the spacecraft hull in a way, that you are not experiencing below 100 km altitude, not even if you fly with a jet aircraft through a strong thunderstorm. A flipped bit is no problem. But designing the necessary analogue circuits in a way to work reliable even outside the pressure vessel is harder.

SpaceX has already mastered such problems in the past, but as you can see easily, not by reinventing the wheel or ignoring past problems. Many aspects of their launchers or spacecraft are extremely conservative and build according to established best practices.

 

[ISProgram]

NSF article on Dragon V2

NASASpaceFlight: "SpaceX’s Reisman ready for the next giant leap with Dragon V2"

 

[Donamy]

Continuing work on Dragon2.

 

[fsci123]

Continuing work on Dragon2.

Dont forget to make it look rough/realistic/dirty...

 

[JonnyBGoode]

I do hope they have backup chutes, just in case. The animation makes it look like it comes down rather fast, right up to the end.