The ESA’s recently launched Solar Orbiter will spend years in one of the most unwelcoming places in the Solar System: the Sun. During its mission, Solar Orbiter will get 10 million kilometers closer to the Sun than Mercury. And, mind you, Mercury is close enough to have sustained temperatures reaching 450°C on its Sun-facing surface.
To withstand such temperatures, Solar Orbiter is going to rely on an intricately designed heat shield. This heat shield, however, will protect the spacecraft only when it is pointed directly at the Sun—there is no sufficient protection on the sides or in the back of the probe. So, accordingly, ESA developed a real-time operating system (RTOS) for Solar Orbiter that can act under very strict requirements. The maximum allowed off-pointing from the Sun is only 6.5 degrees. Any off-pointing exceeding 2.3 degrees is acceptable only for a very brief period of time. When something goes wrong and dangerous off-pointing is detected, Solar Orbiter is going to have only 50 seconds to react.
Fascinating look at a piece of software few of us will ever get to work with.
We used the Windriver VxWorks at University in particular robotics. It was a great OS and its the part of my university i loved the most. Coming from a dos/windows background at the time (mid 90’s) it was so strange to use an OS which was also a live dev environment so you could manipulate VAR’s etc.. at the command prompt, like powershell now (and obviously unix’s / unixi? 😀 ).
It was a chore but the one thing i remember the most is debouncing keyboard / input devices on it. lots of fun, we also had Sun workstations that could emulate a Motorola 68000 processor, as well as a workstation that had the processor directly attached to run code against. It was so fascinating to have a problem, solve it through various gates, design it on the sun machine, test it on the hardware and then put it onto the robot (6 wheeled thing like a RC car nothing fancy).
Loved going through every step of the process, never quite got over the fact that whatever the cursor was hovering over was selected in Solaris, pulled my hair out multiple times when i looked up at the screen and realised i’d been typing for nothing.
Sorry nothing of much to add, just rambling’s from an old man of the bygone years hahahaha
Love RTOS, i was really impressed with the 3.5″ demo of the RTOS QNX in the day, couldn’t believe the OS could load from a disk and was that quick. Great article, very interesting read.
REM2000,
We’re all guilty of it eventually…
Yeah, when you hand-craft the OS, there’s a lot that you can streamline. If you just need to run a single set of programs, you can configure the boot disk to load them in a single large read and it was fast even on a floppy. DOS and others were so slow because they needed to seek lots of sectors creating large bottlenecks. It’s hard to fix this for a generic purpose operating system, but my own OS & kernel weren’t very generic and loaded from floppy almost immediately after bios handoff (akin to seeing a command prompt on a commodore). Modern operating systems like windows/linux/android/ios still take ages to boot by comparison even with the advantages of SSDs. Obviously these are much more complex, but at the same time there’s a hell of a lot of overhead that could be optimized.
If I’m not mistaken BeOS also had a floppy demo ?
Here is a video of the QNX demo:
https://www.youtube.com/watch?v=K_VlI6IBEJ0
screenshots:
http://toastytech.com/guis/qnxdemo.html
And here you can run it online (but the mouse doesn’t work):
https://archive.org/details/qnxdemo_modem_v4
https://archive.org/details/QNX_incredible_1.44m_demo_v4.0
I would think that a dedicated radiation hardened microcontroller for critical subsystems would be just as good, if not better, than a modern CPU running a deadline RTOS. For a program that might cost hundreds of millions of dollars, it’s not unreasonable to give every system it’s own dedicated micro-controller (or even two or three for more redundancy). This way the main processor can be accessed and programmed independently from the steering subsystem. RTOS is cool and all, but consolidating processes seems like it could increase risk of failure, especially in an environment prone to corruption.
Take an earthly example, we could hypothetically use an RTOS for aircraft autopilot, intercoms, onboard entertainment system, etc, in theory it could work, but we’d end up with additional risk and no real benefit; using independent systems would be better for redundancy and overall robustness. It’s notoriously difficult to isolate processes 100% with zero side effects especially on modern CPUs (look at meltdown & spectre where things that were supposed to be isolated ended up not being so isolated). They’ve probably thought about all this stuff, but even an RTOS with mathematically proven software constraints can fail on a CPU that doesn’t always behave predictably under the hood (think about “system management modes” that steal CPU cycles and are not under OS control).
I didn’t see any mention of which CPUs they are using, and for all I know they may be using many independent CPUs for multiple subsystems, I just bring it up as a point of discussion.
What operating systems keep things running in space?
It seems Linux is very big in space with SpaceX using it on their Starlink satellites and Dragon and Falcon spacecrafts
https://www.zdnet.com/article/spacex-weve-launched-32000-linux-computers-into-space-for-starlink-internet/
This is a good publican on the use of Linux in space. The publication is 2 years old which is ancient in computer terms.
https://www.researchgate.net/publication/321788741_Current_use_of_linux_in_spacecraft_flight_software