Live data from Hacker News

How to avoid a BSOD on your 2B dollar spacecraft

clarkwakeland.com

91–100 of 160 posts

Re: How to avoid a BSOD on your 2B dollar spacecraft

#91

Thee are a bunch of comments here asking why one would run Windows on a spacecraft. I am a spacecraft engineer. I don’t see anything in the linked article indicating that they are actually running Windows - the BSOD claim is tongue-in-cheek, or at least that’s how I read it. I also don’t know of anyone anywhere that runs Windows on a spacecraft, with the exception of laptops used by astronauts. Typically one runs vxW…

Linux(with realtime patch) is used very heavily in spacecraft by Spacex. So both in terms of high visibility/important/danger (dragon 2) and high count (starlink) it is very widely used. citation https://old.reddit.com/r/spacex/comments/ncj4vz/we_are_the_s...

And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).

Re: How to avoid a BSOD on your 2B dollar spacecraft

#92

Earlier quoted context omitted.

Linux(with realtime patch) is used very heavily in spacecraft by Spacex. So both in terms of high visibility/important/danger (dragon 2) and high count (starlink) it is very widely used. citation https://old.reddit.com/r/spacex/comments/ncj4vz/we_are_the_s...

And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).

> And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).

why would that be mistaken for a joke?

Re: How to avoid a BSOD on your 2B dollar spacecraft

#93
post #70

Earlier quoted context omitted.

Indeed, and it’s clearly stated in the article: > Safemode is the satellite equivalent of a blue screen of death. It’s about avoiding safemode, and more generally about the end-to-end QA/testing process for satellites before they’re sent up into orbit. It’s very clearly not about actual Windows BSODs, it’s just written in a tongue-in-cheek style. Those commenting about “wtf windows on a spacecraft” clearly didn’t rea…

This would be during formal testing, which is similar to what you might know as “acceptance testing”. The spacecraft doesn’t “enter safe mode” during development. If you’re paying two billion $ for something you become very very interested in test design and test results. Also, safe mode isn’t really the same as a BSOD. It’s a mode where the spacecraft decides something is wrong and disables a lot of functionality an…

So it's a bsod that switches to safe mode instead of halting.

We already got that it's not actually Windows and so not literally identical to bsod in every detail.

It's not the same as a common os safe mode either because it happens by itself as the last resort response to a problem, like a bsod. Not just on command.

Re: How to avoid a BSOD on your 2B dollar spacecraft

#94

Earlier quoted context omitted.

Personally, I wouldn't be stoked to run Linux on them either to be honest. But both are being done. Practicality rules I suppose.

Having sourcecode to everything would make me trust things more as at least we could fix things without calling MS. But what would you run? QNX? BSD?

Maybe sel4? I'm not in embedded so maybe I'm being pretty silly here, but I think being formally proven and realtime are pretty good things to have in the case of an expensive, long lived space project.

That said, this is on the scale that I'm surprised off-the-shelf things are even being considered. I'd have thought they'd just roll something bespoke and that's the end of that.

Re: How to avoid a BSOD on your 2B dollar spacecraft

#95
> I think what surprised me the most was how nonchalant the response was. We had documented all of our actions, so other people had read what happened and knew something had gone on. I wasn’t expecting any fanfare but we weren’t even debriefed on what happened.

That's... Concerning. No root cause analysis? Not even an internal one?

Re: How to avoid a BSOD on your 2B dollar spacecraft

#96
post #92

Earlier quoted context omitted.

And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).

> And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke). why would that be mistaken for a joke?

Because they don't want people confusing the launch pad with left-pad and having the spaceship slowing down because of Facebook Like button embeds.

Re: How to avoid a BSOD on your 2B dollar spacecraft

#97

Earlier quoted context omitted.

Linux(with realtime patch) is used very heavily in spacecraft by Spacex. So both in terms of high visibility/important/danger (dragon 2) and high count (starlink) it is very widely used. citation https://old.reddit.com/r/spacex/comments/ncj4vz/we_are_the_s...

And apparently the astronaut !touchscreen! GUI is written in Javascript (not a joke).

I think I was the person who originally proposed to implement the crew control UI in a web browser, and I participated in a week-long retreat in beautiful Bend, Oregon where we implemented the first prototype.

At the time, some very good flight software engineers had been working diligently on a new UI framework that was written in the same code style and process as the rest of our flight software. However, I noticed a classic problem - we were working on the UI platform at the same time that we were trying to design and prototype the actual UI.

I made some observations:

1) We can create a prototype right now in Chrome, with its incumbent versatility.

2) The chip running the UI can actually reasonably run Chrome.

3) Web browsers are historically known for crashing, but that's partly because they have to handle every page on the whole Internet. A static system with the same browser running a single website, heavily tested, may be reliable enough for our needs.

4) We can always go back and reimplement the UI on top of the space-grade UI platform, and actually it'll be a lot easier because we will know exactly functionality we need out of that platform.

The prototype was a great success; we were able to implement a lot of interesting UI in just a week.

I left SpaceX before Crew Dragon launched, so I'm not sure what ended up launching or what the state of affairs is today. I remember hearing some feedback from testing sessions that the astronauts were pleasantly surprised when we were able to live edit a button when they commented it was too hard to reliably press it with their gloved finger.

As for reliability, to do a fair analysis you need to understand the requirements of the mission. Only then can you start thinking about faults and how to mitigate them. This isn't like Apollo where the astronauts had to physically reconfigure the spacecraft for each phase of the mission -- to an exceptionally large extent, Dragon flies itself. As a minor example of systemic fault tolerance, each display is individually controlled by its own processor. If a display fails, whether due to Chrome or cosmic radiation, an astronaut can simply use a different display.

Also, as a side note regarding "touchscreens" -- I believe some (very important) buttons did launch with Crew Dragon, but buttons and wiring are heavy, and weight is the enemy. If you're going to have a screen anyways, making it a touchscreen adds relatively trivial weight.

Re: How to avoid a BSOD on your 2B dollar spacecraft

#98
post #55

Earlier quoted context omitted.

Linux(with realtime patch) is used very heavily in spacecraft by Spacex. So both in terms of high visibility/important/danger (dragon 2) and high count (starlink) it is very widely used. citation https://old.reddit.com/r/spacex/comments/ncj4vz/we_are_the_s...

I wonder how the integration of PREEMPT_RT is going to affect that technology stack going forwards (I imagine slowly, but it's there now).

It was merged to mainline a week ago.

Re: How to avoid a BSOD on your 2B dollar spacecraft

#100
post #32

Earlier quoted context omitted.

VxWorks, LynxOS or RTEMS. RTEMS is open source.

+1 for RTEMS! Great fully featured RTOS

RTEMS is great, especially impressed with the reliability and performance of the RFS Filesystem:

https://gedare.github.io/pdf/agarwal_comparison_2019.pdf

Post reply on HN