SpaceX: Lessons Learned Developing Software For Space Vehicles
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."
I started my career in nuclear engineering before moving into software development.
There were three really important principles: Redundancy (having several of everything); Diversity (having different implementations i.e. different designs from different manufacturers) and Segregation (keeping things physically separate and firewalled off from each other).
I'm a bigger Linux fan than many here. I've been using it since 1995 and I'm a die-hard Slackware user, but having everything running on the same OS seems like an accident waiting to happen. Yes, I know that it's great that you can have one piece of code that you can compile and run anywhere, and that's easier if you're only using one OS.
However, one of the great things about Open Standards and Open Source was (is) that for many years software was portable so that it could be compiled and run on big- or little-endian 32- and 64-bit POSIX-like systems on a wide variety of CPU architectures.
That may have been "expensive" in terms of software maintenance, but as I learned when working for a now-defunct very large UNIX company, writing your software to be portable across those systems exposes (and forces you to fix) many subtle bugs that otherwise would not have been found until deployment.
Also, relying on just one OS puts you at the mercy of any latent bug in that specific system. Having a diversity of OSes in use mitigates that problem.
The state of Software Engineering in general is still pretty primitive. I'm still amazed at the poor quality of a lot of "professional" code and the cavalier attitude towards testing...In the land of the blind, the one-eyed man is king.
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...
If you want news from today, you have to come back tomorrow.
In his team, they have a full-size Justin Bieber cutout that gets placed facing the team member who broke the build. They found that "100% of software engineers don't like Justin Bieber", and will work quickly to fix the build problem.
You see, that's why you have overflowing prisons. This would easily reduce the crime rate by a factor of ten!
Doubtful. At my $lastjob we had a rule that if you broke the nightly build you bought doughnuts for everyone. And the project lead would rip you a new one.
Despite my admonitions to not check stuff in at the end of the day we had two guys that just couldn't figure it out. One of them worked in St. Petersburg (Russia, not Florida) and he'd check stuff in at the end of his day and go home, meaning we'd be stuck with the dirty job of backing his stuff out so that we could proceed.
And the local guy would whine and cry about how it wasn't his fault, it worked in his tree, yada yada yada. Well, his tree was usually a few days out of date by the time he was ready to check his stuff in, and he just couldn't get the knack of rebasing his tree and building before committing to the master. Sheesh. This stuff isn't rocket science. And as I said, he insisted on doing this at the end of the day – every time. Eventually it cost him his job.
So no, I don't believe the threat of being stared at by a full size cutout of the Biebs would solve crime either.
malloc() and new() are non-deterministic in many ways and therefore to be banned in anything truely real-time.
Don't worry. We now have garbage collected languages where we don't need malloc/free any longer. :-)
The Tao of math: The numbers you can count are not the real numbers.
And they spent years, millions of dollars and thousands of man-hours doing so. I'm sure that the folks at NASA are pretty happy with modern toolsets. My father worked on the Saturn V instrumentation - Op Amps the size of cigarette boxes, telemetry transmitters the size of breadboxes with 300 baud max speeds. Graph paper. Slide rules. Simple changes requiring weeks of rework.
Linux and associated bits and pieces are a big step in the right direction.
Faster! Faster! Faster would be better!
"Linux is mentioned twice in the summary. Is there a reason why?"
2013 will be the year of Linux on spaceships.
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.
A successful API design takes a mixture of software design and pedagogy.