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

61–70 of 112 posts

Re: The software that flies SpaceX rockets and starships

#61

Post by numpad0 »

dom_hutton wrote: post #44
inamberclad wrote: post #42

Earlier quoted context omitted.

There's typically a central time source sending a 1Hz pulse into the main computer(s). The sensors will use something like Time Triggered Ethernet, RS-485, or a MIL-1553 bus.

Yeah this is in line with my experience. However there are concerns about the accuracy of quartz clocks as temperatures fluctuate, this poses a problem for some orbital patterns.

Thanks to both answers - I've asked couple engineers of my generation and "that would be an interesting concept" was the best response I got. I have so much to learn!

Re: The software that flies SpaceX rockets and starships

#62

Post by [deleted] »

7952 wrote: post #37
chmod775 wrote: post #20

Earlier quoted context omitted.

> the larger the mass the more stable the object Not really. Only when scaling mass, margin of error, and forgetting thrust/gravity. And even if you scaled mass, thrust, and margin of error proportionally, you'd still have an object exactly as stable as before (force X applied to the small object gives you the same acceleration as proportionally scaled force Xs applied to a larger object). Gravity accelerates all thi…

A spacecraft may need to be super accurate at docking, but outside of that precision is far less important.

[deleted]

Re: The software that flies SpaceX rockets and starships

#63

Post by ufmace »

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

There's probably no point in going much faster for most control systems of physical devices of the sizes we're talking about. The actual response time of actuators and time to see the results of changes on sensors is much longer. Think the time required to actually adjust the throttle or gimbal a huge rocket engine, and then the time required to see an acceleration change as a result of that.

They probably use higher rates for stuff like measuring combustion dynamics during ground tests of the engines in development. If anything is wrong there, they'll probably seek to correct it via mechanical or fluid dynamics adjustments of the system itself, since active control systems could probably never react fast enough anyways.

Re: The software that flies SpaceX rockets and starships

#64

Post by icegreentea2 »

procarch2019 wrote: post #57
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!

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 like.

Re: The software that flies SpaceX rockets and starships

#65

Post by FpUser »

CodeGlitch wrote: post #59

Interesting they didn't go with MISRA C and used C++ instead.

I think they have a lead or two who were most comfortable doing it the way they like and this is all about it. If you have good software people just step away and do not tell them how to do their jobs.

Re: The software that flies SpaceX rockets and starships

#66

Post by freemint »

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.

Would have been so more funny if you wrote "cloud scale".

Re: The software that flies SpaceX rockets and starships

#68

Post by pyjarrett »

johnisgood wrote: post #60
CodeGlitch wrote: post #59

Interesting they didn't go with MISRA C and used C++ instead.

Interesting they didn't go with Ada/SPARK, to be honest.

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."

Re: The software that flies SpaceX rockets and starships

#70

Post by bdavis__ »

pyjarrett wrote: post #68
johnisgood wrote: post #60

Earlier quoted context omitted.

Interesting they didn't go with Ada/SPARK, to be honest.

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 kept on your desk. and you looked at it on a regular basis. and the compiler was picky (strongly typed).

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

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.

if the first ada compiler was "ada95" instead of "ada83", it would be very popular. it came out a decade before the world was ready.

Post reply on HN