Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The software that flies SpaceX rockets and starships

stackoverflow.blog

Post reply on HN
Print view View original

71–80 of 112 posts

Re: The software that flies SpaceX rockets and starships

#71

Post by procarch2019 »

icegreentea2 wrote: post #64
procarch2019 wrote: post #57

Earlier quoted context omitted.

I’m not sure that I took this away from the article. Looked like they just didn’t go into detail. They mentioned storing data for keeping track of equipment health. To me that sounds like a super broad stroke that would be equivalent to historized time series data as well as contextualized asset data. I’m not familiar with the standards you called out (not an aerospace engineer), but I would imagine it’s similar to w…

I am quite interested to see how they deal with regulations and standards (I'm in medical device space). I scanned through their job postings and I can't find a single standard listed (this is up to the Sr Engineer/Developer positions), as well as a lack of dedicated software QA/test positions. Obviously they are doing some amazing, and quite high quality work, so I am quite interested in what their internal setup is…

Yes, considering how fast they move I’m wondering if it’s closer to self regulated/peer quality control. Some QA/QC can make work come to a screeching halt in biopharma space (makes sense when a “batch” in the cell and gene therapy space is a single person and their wellbeing).

It’s not like regulation and quality have not fallen by the wayside or been too relaxed for other aerospace companies, especially in recent history. Quality should be meaningful and not just a rubber stamp.

It’s a fine line

Re: The software that flies SpaceX rockets and starships

#72

Post by api »

horstmeyer wrote: post #23
sgt wrote: post #4

They're not running a dependency-ridden NodeJS backend with MongoDB and random cloud services? How are they even able to get to space?

MongoDB is web scale, not universe scale.

It's interesting how much contempt people have around here for one of the most successful open source oriented companies in recent memory.

Most of the bad things about MongoDB are actually bad things about the NoSQL fad, and that fad was huge around here a few years ago.

Re: The software that flies SpaceX rockets and starships

#73

Post by ironmagma »

sgt wrote: post #4

They're not running a dependency-ridden NodeJS backend with MongoDB and random cloud services? How are they even able to get to space?

They're only using C++ which has 1,853 pages worth of complexity[1] along with all the toolchains that go on top of it.

[1] https://www.iso.org/standard/79358.html

Re: The software that flies SpaceX rockets and starships

#74

Post by pbourke »

lokimedes wrote: post #58

This article provides an excellent summary of why the defense and space industry is different from “tech”. What SpaceX is doing is normal practice in Defense, but it reads like “1975” when you’re used to TypeScript and cloud instances. I really love my role of spanning the gulf between these worlds. There’s so much to learn from each side to the other.

There are some echos of trading systems (control cycles, publishing telemetry streams, small-world distributed systems).

I was also reminded of James Gosling’s VJUG talk about the Liquid Robotics onboard software for autonomous ocean vehicles:

https://youtu.be/EgUctRxaiLs

Re: The software that flies SpaceX rockets and starships

#75

Post by extropy »

chinathrow wrote: post #24
awestroke wrote: post #22

Earlier quoted context omitted.

That's the frontend. It's fed data by the main computer, but if it crashes nothing else is affected.

If it crashes and Dragon is in manual mode, then what?

The manual controls are a separate system and would still work. And you can peer out of the window for navigation, Apollo style.

Re: The software that flies SpaceX rockets and starships

#76

Post by jcims »

vodou wrote: post #17
zbuf wrote: post #9

Earlier quoted context omitted.

I found this also interesting. I can see how it simplifies the mathematics to use a fixed time interval. Can anyone experienced comment if 10Hz is very different or the same as vehicle control systems such as a modern car? Also, are these systems fixed or floating point? Fixed time intervals would help keep numerical instability of floats in check (however I'd really hope this is more formally understood for such a s…

I've been working on the engine control unit for trucks. I think the fastest control loops were 100Hz (but that was only a few), fixed time intervals. Then, of course, you have the fuel injection that is controlled by its own processor, independent of the ECU scheduling. Nowadays I work with satellite SW. Most of the control loops are pretty slow. The fastest ones are those controlling gyros and reaction wheels that…

PID control loops on brushless motor controllers typically operate in the 5kHz-50kHz range.

Re: The software that flies SpaceX rockets and starships

#77

Post by V_Terranova_Jr »

fallingmeat wrote: post #28

Interesting they seem to ad-hoc the lifecycle processes, or at least no mention of any industry standards mandatory (RTCA/DO-178C, ISO26262 or even sys eng like SAE ARP4754, etc). Also, no talk of formal methods (formal modeling or formal verification, a la DO-333 with something like Simulink Design Verf or TLA+). Works for them obviously!

It's been ~a decade since I was knowledgeable in SpaceX software development details, but at least then, they were not the kind of shop that emphasized rigor and formality. Their culture is oriented toward rapid implementation & test, pragmatism, and empiricism. That has its pluses and minuses.

My personal view is that more of the industry, including SpaceX, should be moving toward engineering things to be more correct-by-construction, including formal modeling & verification as you mention.

As one example, I don't hear most aerospace firms talking about SeL4 for their flight computer RTOSes. For another, you might be surprised (frightened?) by how many vehicles implement their flight software as big single address space executables written in C (sometimes C++) despite running on modern superscalar processors with MMUs. Even static analysis in some of these codebases is relatively recent - they are heavily dependent on functional testing for safety.

Re: The software that flies SpaceX rockets and starships

#78

Post by extropy »

tomxor wrote: post #6
mattlondon wrote: post #5

Interesting that they are doing updates at only 10 and 50Hz. I had kinda assumed they'd be looking at much higher frequencies for telemetry especially for things like the rocket motor metrics

I thought that too initially, but if you think about the physics it makes sense.. the larger the mass the more stable the object, the lower the frequency of acceleration needed to adjust it's trajectory. Also even though it's dynamic, it's not articulated or anything like dynamic robots. Take the opposite, a little quad copter, very low mass, will need very high frequencies. I used to manually fly miniature remote co…

Not mass, size.

You can still have a small but massive flying device and would end up with the same acceleration and jerk because need more thrust to zero the gravity out.

The bigger your thing is the relatively smaller the 9.8 m/s^2 is.

Re: The software that flies SpaceX rockets and starships

#79

Post by jcims »

mattlondon wrote: post #5

Interesting that they are doing updates at only 10 and 50Hz. I had kinda assumed they'd be looking at much higher frequencies for telemetry especially for things like the rocket motor metrics

These are almost certainly global control loops that are orchestrating hundreds or thousands of subordinate control systems that have completely independent dynamics and refresh rates.

Re: The software that flies SpaceX rockets and starships

#80

Post by pyjarrett »

bdavis__ wrote: post #70
pyjarrett wrote: post #68

Earlier quoted context omitted.

Ada/SPARK is pretty close to unheard of in the US. People tend to solve problems with the languages they know and can find people to hire who know it. C++ is fast, and there's a good number of people to hire who know it. Actual comments I've heard from senior developers when I tell them I write Ada in my spare time: - "That language is still around?" - "Other than you, I've never heard or anyone who has ever used Ada…

when i was first exposed to ada, early 1990's, the language was unusable. compile times where excessive (like hours). machines of that era were slow and had small memories (4MB was a common size, and more than 1 CPU was a luxury). i must also admit, ada was hard. you had to do some mojo just to print out a value ("package int_io is new integer_io blah, blah). it had a standard of a couple of hundred pages that you ke…

Ada 2012 is what I learned, but I probably would have moved on if had learned Ada 95. They've done a fantastic job modernizing it, and the next version looks even better (Ada 2022).

> my opinion today is ada is relatively small, makes very fast code, and supports all the programming paradigms of C++ in a very sane way.

This is why I've been sticking with it. I also get pre/post conditions, a real module system (yes, I know C++20), and bounds checked arrays/strings. Easy built-in multitasking has me using concurrency a lot more often as well.

> companies dropped ada because they couldn't hire. C++ people were more available.

I work professionally in C++, and honestly think you could convert a C++ programmer into an Ada one in about a month or so, due to the conceptual similarities.

Post reply on HN