>SpaceX also made use of Chromium and JavaScript for Dragon 2 flight interface. I am not sure how that passed the certification. I assume it was allowed because for every mission-critical input on the display, there was a physical button underneath the display as well<p>I think that's all the validation we need for HTML/CSS/JS as the best tool for UI development nowadays. I wonder if there was actual shared code from the Dragon UI used in their online docking simulator. How neat.
Years ago, astronaut Chris Hadfield told an audience of software engineers (including me) that the moment the space shuttle was in stable orbit, the crew would pull out laptops and set up an ethernet network for all the scientific work of their expedition, as the space shuttle's own computers, though limited in raw computing power, ran software that was so thoroughly tested that there was every reason not to "upgrade" them in any way to support the scientific work.
Good writeup! In general, the direction in modern aerospace is to use COTS (commercial off-the-shelf) parts with redundancy and failback for radiation hardening.<p>If you’re into this sort of thing, I co-write a weekly newsletter about the space industry and often talk about software. <a href="https://orbitalindex.com" rel="nofollow">https://orbitalindex.com</a>
When you think about it from a first principals perspective, having multiple touchscreens is better than only having physical switches. When a switch is damaged/fails, you are out of luck. When a touchscreen is damaged/fails, you use the one next to it. On a rocket you do not have the mass or room to have more than 1 of all but the most critical of switches.<p>There have been quite a few missions that nearly caused death or mission failure directly due to a switch getting broken (Apollo 11, lander return engine-arm switch) or going faulty (Apollo 14 abort switch).<p>What really matters is that they have no single point of failure (touch screens can do everything switches can, an individual touch screen is not important, and switches can cover abort/return scenarios to protect the crew). For the software, it only matters that its been fully tested, including random bit flips and hardware failure.<p>From a cost savings perspective, its vastly cheaper to verify that 3 touchscreens are working correctly than the 600 switches they replace.
Interesting read. I've wondered about their use of big touchscreen interfaces having heard a friend's experience with the similar setup in a Model 3.<p>On multiple occasions they've had to pull off the highway to turn their car off and on again to get the screen working. Not really an option on your way to space.
I would have expected them to use formal verification tools in the vein of TLA+ and such... or maybe use ADA for mission critical systems?<p>But they only mention Astree[1] which seems to be a propietary analyzer for C code<p>[1] <a href="https://en.wikipedia.org/wiki/Astr%C3%A9e_(static_analysis)" rel="nofollow">https://en.wikipedia.org/wiki/Astr%C3%A9e_(static_analysis)</a>
Taken from the article: "We leverage C#/MVC4/EF/SQL; Javascript/Knockout/Handlebars/LESS/etc and a super sexy REST API."<p>Knockout.js, good times.
at the bottom of the article they mention model rockets and the three levels of certification. Each level grants you access to more powerful motors and therefore higher or larger flights. The hobby is self-goverend by NAR and Tripoli who manage level certification.<p>It's a fun hobby, although large motors get pricey. The largest can be 4-5 figures per launch. However, you can get very advanced and do things you wouldn't typically expect in a hobby.<p>Here's a two stage ( 4" diameter booster, 3" diameter sustainer ) reaching over 200k feet in altitude. The Karman Line is about 330k feet.<p><a href="https://www.youtube.com/watch?v=g0imcpdLdB8" rel="nofollow">https://www.youtube.com/watch?v=g0imcpdLdB8</a>
I'd love to work with physical software (software that interacts with the real world through sensors and actuators), as a C developer, how should I move into this space? Every time I try intro to ARM kits I feel like I'm in over my head.
A thread from a few days ago: <a href="https://news.ycombinator.com/item?id=23368109" rel="nofollow">https://news.ycombinator.com/item?id=23368109</a>. The current article quotes from it, in fact.<p>This article looks like a fine overview but when it comes to follow-up posts, the test is: does the new submission contain enough SNI (significant new information) to support a substantially different discussion? In this case it looks like not, but I can't really tell.<p><a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%22significant%20new%20information%22&sort=byDate&type=comment" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...</a><p><a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20follow-up&sort=byDate&type=comment" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...</a>
No mention of Ada or their methods of writing the important software. I wonder what they use.<p>"Avionics Test team<p>...The main objective is to write very comprehensive and robust software to be able to automate finding issues with the hardware at high volume...."
The astronauts show parts of the touchscreen and physical controls here: <a href="https://youtu.be/llbIzbOStt4?t=150" rel="nofollow">https://youtu.be/llbIzbOStt4?t=150</a>
It would be awesome if some SpaceX engineers would give a few presentations at events like CppCon and talk about their software development process including some code examples and demos.
Hearing about the Flight Software and Avionics teams reminds me of this, although they don't seem to be on that level quite yet.<p><a href="https://www.fastcompany.com/28121/they-write-right-stuff" rel="nofollow">https://www.fastcompany.com/28121/they-write-right-stuff</a>
I wonder how they manage not to have accidental taps on the touch screen during liftoff and or re-entry. As I understand there are a lot of G's and violent vibrations and I would assume it's hard to keep a steady hand?<p>(Atleast this is my understanding from watching Apollo documentaries/movies etc.)
I'm so relieved to hear all the redundancy and testing in place. I had heard that the touchscreens were built in Chromium/JS and was rather alarmed. Don't get me wrong – I do a lot of web stuff and I love that environment, but I've never seen a web app I would trust two human lives to. This, however, sounds like they really thought it through and made it safe.
Does this article imply that RTCA/DO-178B is used as a means of demonstrating compliance in some way, or otherwise is used to define lifecycle processes for their development/verification/systems teams? Anyone know where this was mentioned by SpaceX?
> The Flight Software team is about 35 people.<p>I'm shocked the discussion is about UI tech and not that there was only 35 people on the team that built the software to land Falcon 9.<p>Surely it's changed in the last 7 years. Anyone know the size now?
They will be doing an AMA on Reddit again soon according to <a href="https://youtu.be/y4xBFHjkUvw?t=674" rel="nofollow">https://youtu.be/y4xBFHjkUvw?t=674</a>
> The secondary ports go into the primary ports, which are heavy-duty actuators that connect to what’s called a “summing bar,” which is no more than a massive steel rod.<p>"In Rod We Trust"
touch screens are a bad choice to me<p>I want the buttons and knobs.<p>Love the old soviet control rooms posted awhile ago: <a href="https://designyoutrust.com/2018/01/vintage-beauty-soviet-control-rooms/" rel="nofollow">https://designyoutrust.com/2018/01/vintage-beauty-soviet-con...</a><p>Need John Carmack's opinion of SpaceX