|
|
|
|
|
|
by MycroftJones
2082 days ago
|
|
|
Short answer, to save you reading the article: VxWorks. But there may be more interesting info on pages 2 or 3 of the article. I am curious how VxWorks manages the update procedure. How does it do what it does. How is remote debugging in space using VxWorks; is it anything like the Lisp stuff that JPL used to do? |
|
|
There are some surprising structural similarities between the Lisp and vxWorks environments, particularly in terms of managing updates. vxWorks includes facilities for loading and linking code on the fly, and it also has a kind of REPL, though it is more akin to an interactive GDB session than a Lisp listener. But you can read out memory, load new code, stop and start processes, even do hot patches.
Now, none of this is done casually. You don't just randomly type things at the vxWorks shell and hope for the best. You're dealing with a multi-hundred-million-to-billion-dollar asset and a round-trip light time easily in the tens-of-minutes to hours range. Any interaction is carefully planned, exhaustively tested on the ground, and then carefully vetted through a review process that sometimes resembles a religious ritual or a comically overwrought scene from a bad science fiction show. A proposed course of action is packaged up, approved by a chain of management who don't really know the technical details of what's in it but whose careers depend on it working properly, and then forwarded to an appropriate DSN antenna for uplink. The actual Big Red Button (nowadays its a keyboard) is pushed by someone who has no idea what it is that he or she is sending, their job is just to make sure that what is being sent is the thing that was approved. The entire process is designed so that if something goes wrong, every step that led up to the problem can be reconstructed so that the cause can be found. Fortunately, that is very rarely necessary.
Then everyone sits around and waits nervously while the photons go from A to B and back again.