SpaceX: Lessons Learned Developing Software For Space Vehicles 160
jrepin writes "On day two of the 2013 Embedded Linux Conference, Robert Rose of SpaceX spoke about the 'Lessons Learned Developing Software for Space Vehicles.' In his talk, he discussed how SpaceX develops its Linux-based software for a wide variety of tasks needed to put spacecraft into orbit—and eventually beyond. Linux runs everywhere at SpaceX, he said, on everything from desktops to spacecraft."
Re:Max Length (Score:5, Informative)
Okay, somebody ban this guy...
"You must be new here".
Do you actually believe that trolls are "banned" at Slashdot?
That's what the moderation system is for.
Slashdot is not like other "forums" in that it is *not* "moderated" by "super users", but rather regular users like you and I who are occasionally gifted with "mod points".
The "offending" post is never removed, it is just pushed below most users viewing threshold.
Seriously, "ban this guy"? You *MUST* be new here...
Re:Learning from NASA's experience ... (Score:5, Informative)
And obviously you think -- I find it a common misconception -- that SpaceX is reengineering everything from scratch, including the engineering process itself. Well, here's a wakeup call for you: they employ plenty of people with lots of legacy space mission experience. The choice of the kernel is a minor thing in the grander scheme of things.
Re:Garbage (Score:3, Informative)
You might have noticed the three characters at the very end of my post. A colon, followed by a hyphen, followed by a closing parenthesis. You might want to inform yourself about the meaning of this letter combination. Here's a hint: It is known as smiley. Google for it. You might get enlightened.
See also: Whoosh.
Re:Learning from NASA's experience ... (Score:4, Informative)
Back in those days, the problem with "random flip bit", brought on by space radiation was already present
Apparently NASA has successfully dealt with that phenomenon - or a lot of NASA's spacecrafts would have spun out of control
Except that the problem with "random bit flips" was relatively minor, because:
1) The AGC CPU's were much larger and less vulnerable to high energy particles, using basically the first generation of Intel NOR gate circuits (I believe there were two NOR gates in a single IC package back then) with large feature size.
2) The RWM was realized in form of a matrix of magnetic cores, which are completely unaffected by high energy particles,
3) The ROM was realized in form of "ropes" of huge magnetic cores (which, again, are completely unaffected by high energy particles) threaded with wires in an elaborate way.
The actual threading of the wires was done by elderly women with skilled hands, according to a translation of the machine code to instructions for the women as to how to thread the wires. I guess you can imagine the turnaround rate. Punch cards are a lightning-fast way of programming computers, compared to this.
Given the extent to which active feedback control has replaced a lot of hardware in modern high technology, and how everything is so much more self-diagnostic, self-tuning, and remotely monitored these days (look at car ECUs, for example), I *seriously* hope you're not trying to say that we should build and program a modern spacecraft control computer this way.
We have different electronic technology nowadays, and we have different manufacturing technology to build the electronic components, and we have to use completely different approaches to deal with different problems (or rather, different solutions for the old problems) that this brings.
You sound like the people who keep asking "Why don't we just build the Saturn V again?" The answer is still the same: "We can't, even if we had all the plans, Saturn V was designed to be built by hand with power tools and toolings that nobody uses anymore, we have to design a CNC-buildable rocket and it's simply going to be different." In the case of electronics, the answer is analogical, we have to re-solve the old problems in terms of new electronic components.