31–40 of 128 posts
>This all has to happen without any human intervention, so the central computer software has been programmed and extensively tested to make sure all corrections can be made on the fly. I'd love to get some deeper insight into how NASA writes and tests software, I can only guess it's a million miles from how most of us work. Anyone know of any good talks, articles from engineers there?
>Another challenge came in the form of the electronic wiring — most cables would melt from exposure to heat radiation at such close proximity to the Sun. To solve this problem, the team grew sapphire crystal tubes to suspend the wiring, and made the wires from niobium. are these wires on the outside of the spacecraft? but what about the silicon of all the electronic stuff that this thing must be keeping? The cooling…
Melting points: sapphire - 3,722°F (2,050°C) niobium - 4,491°F (2,477°C)
Earlier quoted context omitted.
The part that I find the most intriguing is "corrections can be made on the fly". I can see how you would ensure reliability through proper requirements specification, a good software development process, separate independent implementations and extensive verification. However, every time I read a popsci article about space flight software, they talk about this capability to push new code to the spacecraft while it i…
From previous articles, remote updates seem to be a core part of spacecraft software/operating systems. I even recall one situation where a spacecraft had a REPL built in that was used to fix a problem (slowly) remotely! They also have multiple levels of operation and watchdog functionality. I have no direct experience with that beyond following news about spacecraft.
But: Once you include a REPL or another mechanism to push and execute arbitrary code "ad-hoc", I wonder how that could possibly be tested an validated? Surely as soon as you add the ability to run arbitrary code, there is no way of testing for all possible states of the system as part of the validation process?
In other words, how do you allow the user to push arbitrary code, but prevent them from putting the spacecraft into a condition from which it can not be recovered? The only way I could naively think of would be to only allow the user to push code to a completely isolated CPU that has a remote-reset functionality from the main/comms CPU.
Still, the popsci articles I read made it sound like there might be more to it. It would be excellent to find some first-hand accounts/sources on how this looks like in reality.
>This all has to happen without any human intervention, so the central computer software has been programmed and extensively tested to make sure all corrections can be made on the fly. I'd love to get some deeper insight into how NASA writes and tests software, I can only guess it's a million miles from how most of us work. Anyone know of any good talks, articles from engineers there?
The part that I find the most intriguing is "corrections can be made on the fly". I can see how you would ensure reliability through proper requirements specification, a good software development process, separate independent implementations and extensive verification. However, every time I read a popsci article about space flight software, they talk about this capability to push new code to the spacecraft while it i…
My understanding is that some spacecraft launch with beta/alpha equivalent software. Correct me if I'm wrong, but I believe that the rovers do this, with simple software installed first, then more complicated versions installed once they know everything is working.
It's somewhat similar to updating your iphone, but instead you use a huge dish to do the transmission and the bitrate is pretty horrendous.
I'm going to need a definition of "ad-hoc" here; no-one "deploys straight to production" on a spacecraft. Any patches have to be thoroughly tested on simulators and models of the spacecraft on earth before they are transmitted.
>This all has to happen without any human intervention, so the central computer software has been programmed and extensively tested to make sure all corrections can be made on the fly. I'd love to get some deeper insight into how NASA writes and tests software, I can only guess it's a million miles from how most of us work. Anyone know of any good talks, articles from engineers there?
Earlier quoted context omitted.
Here's an article about it I read a while back, interesting read: https://www.fastcompany.com/28121/they-write-right-stuff
This redundant software and hardware setup typically isn't necessary when humans aren't involved. The space shuttle system is similar to what you will find on a Boeing or Airbus aircraft. Redundant software, written by different people in different countries with completely different cultures in different languages (on purpose), running on multiple machines with different hardware and voting on the decisions to be ma…
Earlier quoted context omitted.
The part that I find the most intriguing is "corrections can be made on the fly". I can see how you would ensure reliability through proper requirements specification, a good software development process, separate independent implementations and extensive verification. However, every time I read a popsci article about space flight software, they talk about this capability to push new code to the spacecraft while it i…
There is usually a piece of software running on the machine which basically just does this - allows you to command an image upload to the SSD, do a checksum of the file, then install it if all goes well. There is also usually a simpler version of the software on a redundant SSD or partition which the onboard computer will install if it detects that the software that is currently installed is malfunctioning. My unders…
Wouldn’t you want the benefit of those extra months to perfect the software?
Earlier quoted context omitted.
Here's an article about it I read a while back, interesting read: https://www.fastcompany.com/28121/they-write-right-stuff
This redundant software and hardware setup typically isn't necessary when humans aren't involved. The space shuttle system is similar to what you will find on a Boeing or Airbus aircraft. Redundant software, written by different people in different countries with completely different cultures in different languages (on purpose), running on multiple machines with different hardware and voting on the decisions to be ma…
If anyone is interested JPL publishes their code standards doc for C: https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
Earlier quoted context omitted.
From previous articles, remote updates seem to be a core part of spacecraft software/operating systems. I even recall one situation where a spacecraft had a REPL built in that was used to fix a problem (slowly) remotely! They also have multiple levels of operation and watchdog functionality. I have no direct experience with that beyond following news about spacecraft.
Remote updates -- where you replace a full (sub)system -- are one thing, since you can always run the normal software validation procedure on the new version of the software. So an OTA update of a system (even in flight) does not sound like rocket science (yet)... But: Once you include a REPL or another mechanism to push and execute arbitrary code "ad-hoc", I wonder how that could possibly be tested an validated? Sur…
Lights-out management indeed.
Dad joke: "They'll go at night" But really, it's cool that they're using carbon-carbon protection similar to that which was originally developed for the leading edges of the Space Shuttle. And I really want to know how they built foamed carbon for the interior. I'm guessing that they're using white ceramic paint on top instead of a reflective foil shield (like the Webb uses) because the foil would be shredded by the…
I'm curious about the foam, too. Normally, foam contains a lot of air. But that kind of foam will blow itself apart in a vacuum. How do they make foam where all the air pockets are replaced with vacuum? Is vacuum-filled foam a better or worse insulator than air-filled foam?