Solar Orbiter: Data Handling Lessons Learned

The ESA/NASA Solar Orbiter launched on 10th February 2020, to start its mission to obtain detailed measurements of the inner heliosphere and the nascent solar wind, will also perform close observations of the polar regions of the Sun. It is equipped with a suite of ten payload instruments comprising both remote sensing and in-situ sensors. The instruments communicate to the onboard mass memory over a SpaceWire “network” comprising several interconnected routers which are part of the mass memory unit. Communications between instruments and the on-board computer are also through this network, with all traffic passing through the mass memory unit. This network topology has resulted in multiple problems in-flight which we consider to be architectural problems with the everything-through-the-mass- memory approach. Problems have occurred with individual instruments, with the mass memory unit and with the mass memory / on-board computer link; the architecture of the SpaceWire network has meant that in most cases the failures rapidly affect all of the connected units, either by dropping packets or link disconnection events. That is, if someone has a problem, everyone has a problem. This paper will look in detail at each of the failure cases and establish how the network architecture was a contributing factor. In contrast, the platform units are all connected on a classic MIL-STD-1553b bus with fixed data frames, which has been extremely robust despite occasional unit-level communications error. We compare and contrast the two approaches and extrapolate lessons which can be learned for future complex deep-space missions.