Live data from Hacker News

What computer and software is used by the Falcon 9? (2015)

space.stackexchange.com

131–140 of 160 posts

Re: What computer and software is used by the Falcon 9? (2015)

#131

Sounds kinda disappointing/irresponsible. Chromium is an overly complex, relatively buggy piece of software. For example I recently experienced a bug where a text I selected was significantly offset from what should have been selected given the pointer position (on linux), a misclicky kind of bug. Considering that the majority of Crew Dragon's controls are through touch screen, maybe even manual docking(not sure, but…

In the case of SpaceX, it seems that they use embedded Linux and C++ with x86 processors, same as standard PC processors. A reason for using embedded linux is that, it allows using standard C++ or even scripting languages for controlling the hardware from the user-space by just reading and writing files. Linux device drivers (aka kernel modules) maps the hardware to special files on /sys or /dev. For instance, it makes possible to control a GPIO (General Purpose IO) which the device driver maps to sysfs special file system, by just writing 1 or 0 to the file a like /sys/class/gpio/gpio4/value which would enable GPIO 4 and turn on a LED attached to it. Another practical example about this feature is that, on Linux, it is possible to turn on or turn off the keyboard capslock LED by writing to some /sys/class/leds file such as "$ echo 1 > /sys/class/leds/input7\:\:capslock/brightness" which turns on the Capslock LED. By writing 0 to it, the LED is turned off.

This feature of Unix and Linux allows controlling the hardware with any programming language capable of reading and writing files, including Python and standard C++. I guess that they may be using standard PC hardware with industrial IO card. They may also use a single-board computer or custom board with x86 low-power variants processors built for embedded applications as SOC system-on-chip. One example of low power x86-SOC based processor is: https://www.cnx-software.com/2015/04/09/vortex86dx3-is-a-new...

Re: What computer and software is used by the Falcon 9? (2015)

#132
post #126
post #83

Earlier quoted context omitted.

It is never persisted outside of RAM. The flight computers are never powered off during a mission. You rely on two flight computers to always be functioning, that’s why the system is one-fault redundant. You can think as each string being “functional“: given the same set of inputs you expect the same set of outputs.

What happens if some anomaly happens where the shuttle loses power for a second?

Are you asking about what happens if all the power goes out or are you asking how they get state back? If everything reboots it’s fine. On restart the computers will look at all the sensors add project the state of now. There is no reason to keep the state of the past is there? Why does it matter where the craft was 5 minutes before? What matters is what is what is in front of them and the future right? If you tell the computer I want to fly home it looks at where you are and tells you how to get there. It does not need to remember the past parts of the trip does it?

Re: What computer and software is used by the Falcon 9? (2015)

#133
post #33
post #11

Earlier quoted context omitted.

I believe the choice of Chromium and JS for the UI simply shows that the astronauts are merely inconvenient payloads. Gagarin's first flight was already fully automated 59 years ago.

The UI design consisting exclusively of elegant but low contrast shades of blue certainly gives a similar vibe. But that might still be misleading, perhaps they deliberately keep the routine visualizations in a low key "style over substance" passenger entertainment mode so that they have plenty of visual headroom for when something actually important combs up?

This reminds me of the Airbus concept. They follow what's called a "lights out" design for all of those buttons on the overhead panel. When things are set and working the way they should be for normal flight, there is no indication. Only if something is non-normal does the indication or button light up.

For example, buttons that should be "on" for flight only light up when the system they control is "off", and things like emergency overrides or backup systems that should be "off" normally have buttons that light up when they're "on".

It's an interesting concept. Obvious benefit is you can glance at the overhead panel and instead of having to consider the state of, say, 50 or more buttons, you can instantly see if everything is "normal" for flight. But the downside is that it's not as intuitive to answer the question "is system X turned on (or off)"...you have to look at the button, then know what's considered "normal" for that system, on or off, and determine if the lack or presence of indicator light means on or off. That said...the pilots know the plane well enough where it's not a problem.

Re: What computer and software is used by the Falcon 9? (2015)

#134
post #5

I’m now curious about their memory structure, are they just using off the shelf multibit ECC memory?

You might need multibit ECC also in CPU caches. Pretty much all CPU caches have ECC, but no idea how large of an error they can fix. Then again, probably control logic is running on something radiation hardened and GUI layer (with some redundant hardware) can be easily rebooted as necessary.

I don't think that's necessarily true. I've worked with a couple of cacheful CPUs that only used parity checks on caches, not ECC. To get safety, the cache has to be set up as write-through instead of write-back, so that it is almost always safe to throw away a line that suffers a parity error.

Re: What computer and software is used by the Falcon 9? (2015)

#135
post #120
post #109

Earlier quoted context omitted.

How well do you actually know LabVIEW? Have you ever used its object-oriented system, actor framework, network streams, or get/set control value by indices (a feature actually implemented for SpaceX) functionalities? These are all things a professional LabVIEW engineer will be familiar with and use. The fact that a system didn't use these means it's either seriously outdated or the person writing it wasn't aware. It…

This is definitely fair--I don't consider myself a LabView expert. I'm proficient with object-oriented systems (Python, C++, Rust (if you consider Rust object-oriented)), with get/set for indices and network streams, but not familiar with actor frameworks outside of a passing read-some-docs a few times. I'd estimate I've cumulatively spent around a month working on LabView full-time, including writing/editing several…

Just a few clarifications. By get/set control values by indices I meant a specific feature in LabVIEW that allows high-performant updates of front-panel controls. You use these when you have a lot of data being streamed to the front panel. By network streams, I again meant a specific LabVIEW feature (https://www.ni.com/documentation/en/labview-comms/latest/dat...) for sending data back and forth over Ethernet. It's a nice high-level library that is performant. It just makes it extremely easy to pass data around. In any big system, these features are a must-have. Also, I wasn't judging, so apologies if it came across that way. :) There's just a difference between little small systems that don't use LabVIEW's features and those that do. Most people who have used LabVIEW to its full extent have completely different complaints than those whose experience revolves around university or internship LabVIEW software, and so I like to point out that LabVIEW isn't fundamentally flawed as a visual language.

I think that the when properly architected asterisk applies to any language. LabVIEW is in a difficult situation because there are two huge factors at play. It makes it easy to start off and get things going, but systems inevitably grow beyond their original scope, and so LabVIEW systems are often developed by non-software people but still expected to grow. That's a conflict. The second thing is that more traditionally trained programmers have a mental block when it comes to LabVIEW, so people who do know how to properly modularize code don't pay attention to LabVIEW. So in LabVIEW, you have some experts who do treat it seriously, as if it was any other software system, but then a lot of code that was thrown together by others new to software and to LabVIEW. I would say Python is actually in a very similar situation by being "friendly" to beginners, so there is a ton of bad Python code out there.

I once interviewed at a place that had completely sworn off LabVIEW. I couldn't get them to explain why. They just hated it. But then I asked to see their Python code, which is what they had moved to, and I was greeted with a single file that was 10,000+ lines long. And in there I saw some function signatures that were 15-20 lines long (yes, the function's arguments spanned that many lines). So I see that as a disconnect. They hated LabVIEW but didn't know why and loved Python and didn't know why. In either case, they didn't know what they were doing.

The .NET APIs NI makes are nice enough, and I have used them before but not to a deep degree.

Re: What computer and software is used by the Falcon 9? (2015)

#136
post #6

Earlier quoted context omitted.

Just because they do, doesn’t mean you should. I’m running an automotive firmware project at the moment and there are such things as software integrity levels, and each time you add something to the stack you create quite a large amount of testing and validation and process that needs to be followed. And it’s pretty much impossible to take something existing like Chromium and certify it to what you need. The architec…

But mixed-criticality systems are quite normal in many deployments nowadays, especially with the advent of virtualization and hypervisors you should be able to run safety critical and non-safety critical functions at the same time on the same SoC.

Yes, but you have to prove that if one display considered to be "non critical" shows misleading data, it will not cause harm to the crew. For example, if the Chromium crashed and showed the heading or fuel level incorrectly, would they fly the rocket ship into the ocean or run out of fuel and drop out of the sky.

Yes, it's called software integrity decomposition, and it's complicated and requires much analysis.

Re: What computer and software is used by the Falcon 9? (2015)

#137
post #24

Earlier quoted context omitted.

Just because they do, doesn’t mean you should. I’m running an automotive firmware project at the moment and there are such things as software integrity levels, and each time you add something to the stack you create quite a large amount of testing and validation and process that needs to be followed. And it’s pretty much impossible to take something existing like Chromium and certify it to what you need. The architec…

I think it is not helpful to call out that their architecture is "wrong" and their process is "wrong". The attribute "wrong" is very opaque. As somebody who doesn't have your background, i cannot follow you. I have no idea about automotive and space software requirements. Since there are many aspects that lead to choices of a system architecture it requires more words to explain why a choice is not a good choice for…

I was referring to the architecture of Chromium being wrong to achieve certification for safety critical applications.

And look, I haven't said impossible, but rough estimate I'd say removing 75% of the features and 5+ years to rewrite it to be compliant. And the subset of javascript that it could run would be very limited - it might not even have loops or functions.

Re: What computer and software is used by the Falcon 9? (2015)

#138
post #109

Earlier quoted context omitted.

How well do you actually know LabVIEW? Have you ever used its object-oriented system, actor framework, network streams, or get/set control value by indices (a feature actually implemented for SpaceX) functionalities? These are all things a professional LabVIEW engineer will be familiar with and use. The fact that a system didn't use these means it's either seriously outdated or the person writing it wasn't aware. It…

I have written and maintained a piece of testing/control software. It was originally horrible “old” spaghetti Labview. I maintained it for a while then wrote a replacement with Labview’s actor framework. I agree that the AF seems to be the only reasonable way to write certain kinds of larger application. However, the actor framework was, for me, just barely good enough to be usable. - The debugging story is very bad:…

I agree with your complaints. Indeed, implementing an abstract message is awkward, although there was a specific version that did improve the project interface to make that easier at some point. I remember a relief of "finally". Haha. The right-click menu for the actor framework is implemented using project providers and LabVIEW scripting, both of which need massive improvement. It's an awkward process to even get the license to implement project providers as a user. I've just ignored them because I'd rather just write custom tools off to the side that use LabVIEW's application control system manually. And there's also a lot of ideas I have that require scripting, but it's not an easy system to use.

I also agree with the actor framework being too bare bones, and there are plenty of things I disagree with in the design. That's why I extended it myself to add in additional support. For example, I added built in messages to notify when an actor is ready, a publish/subscribe mechanism to break out of the recommended hierarchical setup when needed, a streaming actor that you can subscribe to the data it streams out via messages, a finite state machine actor that allows state transitions triggered by messages or internal requests and message mechanisms to notify when this happens to subscribers of the state updates, and some more.

> There is no concept of supervision trees, so if you want “let it crash” robustness, you’ll be writing that yourself

Yea. I recently learned Elixir/Erlang to some degree. I'd like to have an OTP-like system in LabVIEW. The above extensions are actually already close in some ways. For example, the FSM actor I made is similar to gen_fsm or gen_statem in OTP.

> I want to point out that despite how personally ugly I found the experience, I’m not sure there was a better choice.

Therein lies the rub. I've searched for one. Despite my complaints about LabVIEW, I end up finding other systems even harder to work with for these applications. Elixir/Erlang are great, but developing a user interface with them will require web-technologies. C#/F#/.NET is the other system I've identified, but it's a fairly complicated ecosystem. And what language allows me to do desktop apps, web apps, web servers, real-time deterministic programming, and FPGA programming all in the same language and environment? It's a tough feature set to replicate and replace.

Re: What computer and software is used by the Falcon 9? (2015)

#139

Earlier quoted context omitted.

Could you name few better than js?

In the context of writing reliable software for a spacecraft? Pretty much anything with a reasonable type system, for a start. Maybe C#, or some reasonable subset of C++20, or Rust. Maybe Reason or OCaml.

I mean very clearly the good people at SpaceX have heard of these languages and decided against it. I think JS and Chromium are the best UI kit I can think of in terms of man hours to get X done. If you're careful the only thing I've ever had issues with is latency, but in space if you're in a situation where missing a frame or two is important you're already beyond fucked.

Re: What computer and software is used by the Falcon 9? (2015)

#140
post #100

Knowing that the ground control software is written in LabView is one of the more disappointing things I've read recently. I did a bunch of test engineering during co-ops during college, including multiple "codebases" of LabView, plus the normal class coursework and research lab instrumentation. I hate LabView, to the degree that I made a commitment never to apply to a job that has it's use as one of the requirements…

I think another thing that is often overlooked is that a project like this requires a ton of very diverse hardware in the form of hundreds or maybe thousands of sensors, valves, PLCs etc. A rocket launch site reminds me a lot of an industrial process facility. National instruments sells all of that hardware with LabView as a complete solution. Their PXI systems, which are used extensively in the process industry, are quite expensive up-front but the seamless integration of the hardware with Labview drivers, Teststand etc makes it so much more cost-efficient down the line.
Post reply on HN