How RMAP improves in-flight update of on-board software via SpaceWire

Modern space probes such as Solar Orbiter employ a SpaceWire network to connect to on-board computer (OBC), solid state mass memory (SSMM), and scientific instruments. Management of SpaceWire links within scientific instruments is typically performed by a data processing module (DPM) featuring a space qualified processor that is executing on-board software. To adapt to changing mission requirements, account for failures and fix possible software bugs, the ability of uploading and patching instrument software is mandatory. However uploading and over-writing of the software's boot image cannot securely be performed by the software itself. If over-writing the boot image fails, the remaining image might be corrupted. So the processor may not be able to reboot successfully and no further upload would be possible. Therefore reception of uploaded patches must be performed by an independent entity. Currently, this is accomplished by a dedicated boot loader in separate memory area, to be qualified according to ECSS criticality category B. This boot loader processes uploading of patches and copies them to the second boot area, where the actual software including the operating system is stored. Due to the opportunity of modern processors to handle SpaceWire RMAP accesses (e.g. SpW-RTC, UT699, GR712RC [1], or upcoming NGMP [2]), it would be possible to perform uploading and patching of the instrument software independent of software execution using RMAP. This would dramatically simplify the development, eliminate the need for a class-B qualified boot loader, and will inherently improve reliability, as reception of patches would entirely be performed by hardware. This paper presents a possible update and patch process for boot images using hardware based RMAP features. Furthermore implications of the standard ECSS services affecting such patching routines are discussed.