Article Index

The Instrument Data Handling Unit (IDHU)

Following the concept behind the organization of the THESEUS instruments as well as the decentralized avionic scheme, each of the three instrument payloads will be equipped with a dedicated Instrument Data Handling Unit (I-DHU) that will serve as their TM/TC and power interface to the spacecraft. The aim of this scheme is to provide sufficient computing power and data storage to the individual instruments and thus to realize a decentralized data handling function.

The mechanical and electrical design of the I-DHUs (described below) will be the same for all three instruments. Also the operating system and basic software that is running on the Processor Board inside each I-DHU will be the same. In addition, an instrument specific data processing software will be run on each I-DHU, implementing e.g. the above mentioned trigger algorithms and event detection codes.

The computational load on the I-DHU is an high margin, which allows the use of a much simpler, off-the-shelf processor with flight heritage on the Processor Board with the load being easily sustainable with still a large margin. The tasks of the I-DHUs can be separated into three main categories, namely data processing, instrument controlling and power distribution. In order to acquire/process the scientific data, the I-DHUs will:

  • collect, process and store the data stream of the respective instrument

  • implement the burst trigger algorithm on SXI and XGIS data

  • implement the IRT burst follow up observation


I-DHU design overview

The I-DHU consists of two main boards that are mounted inside an aluminum case. In addition, each board exists in a cold redundant (identical, non operating) version inside the box, that can replace the nominal board in case of a failure. Switching between the nominal and redundant chain is done from ground via the spacecraft by activating the SpaceWireLink of the respective data processing board.

At the heart of the I-DHU design is the Processor Board. It hosts the central CPU, the mass memory, time synchronization and distribution circuits and the HK/health monitoring acquisition chain. The Processor Board is connected to the spacecraft via one SpaceWire link through which it will receive the telecommands (TC) and send the science and HK/health data. On the other hand, the I-DHU is connected via another Spacewire link to the respective instrument to relay the TCs and acquire the science and HK data. The SpaceWire interface communication is handled directly through the main CPU (description see below), via its existing dedicated hardware interfaces. The CPU is running an RTEMS (Real Time Executive Management System), an operation system (OS) on which the individual software tasks (detailed description below) of this I-DHU will be run in parallel. Dedicated circuitry is foreseen on the Processor Board for the collection, digitization and organization of HK and health data from various voltage, current and temperature sensors. This will reduce the HK tasks on the main CPU, leaving only the science meta data (like rate meters, counters) and dedicated instrument data processing to be done there. The Processor Board will be developed by the IAAT in Tübingen, Germany.

The Power Board within the I-DHU will be developed by the Centrum Badan Kosmicznych, Poland. It will generate the voltages for the Processor Board and distribute the power to the instrument.


I-DHU mechanical and electrical design

The I-DHU design is based on already developed hardware components with flight heritage or qualification and thus a relatively high TRL. It is based on a single mechanical box containing all electronics and connector interfaces. This particular design has a direct heritage from the eROSITA Interface Control Unit boxes and has as such been qualified already with PCBs during the qualification of the eROSITA telescope structural model and has been shown to withstand the conditions of a launch very well. The mechanical and thermal interface to the platform is realized via six fixations on the bottom plate of the box.


  • 24
  • 25

Figure 15. Left: Block diagram of the GR712RC architecture. Right: Overview of I-DHU dimensions



I-DHU Central Processor and Software

The baseline processor for the I-DHU data processing board is the GR712RC (see Figure 15 Left), a dual-core LEON3FT SPARC V8 processor. It has been developed for high reliability Rad-Hard aerospace applications by Gaisler Aerospace. The GR712RC architecture is centered around the AMBA Advanced High-speed Bus (AHB), to which the two LEON3-FT processors and other high-bandwidth units are connected. Low-bandwidth units are connected to the AMBA Advanced Peripheral Bus (APB) which is accessed through an AHB to APB bridge.

The main functions of the I-DHU on-board software are instrument control & health monitoring and science data processing & formatting. The software will be designed in order to allow the instrument to have the complex functionality that it requires to allow itself to be updated and work around problems automatically and with input from the ground. There will be a common software that is the same for all I-DHUs and an extended software part with modules specific for a given instrument. An example of a software module common to all I-DHUs is the determination of the location of a burst or transient event. The time and location of the transient will be transmitted to ground using the onboard VHF system in a < 1 kbit message. The design of the trigger software benefits from the heritage of the SVOM mission concept as well as past team experience on similar systems on BeppoSAX, HETE-2, AGILE as well as the INTEGRAL burst alert system.

I nstrument control will be possible through the software via telecommands from the ground (e.g., power on & off forindividual units, loading parameters for processing/on-board calibration, investigations) and autonomously on-board (e.g., mode switching, FDIR and diagnostic data collection). The software will implement the standard ECSS-style PUS service telecommand packets for housekeeping, memory maintenance, monitoring etc. and some standard telemetry packets for command acceptance, housekeeping, event reporting, memory management, time management, science data etc. The software will be able to send setup information to the instrument and receive and process the housekeeping data coming back and organize these data in a configurable way for a lower rate transmission to the ground. Figure 16 shows the commandable operational modes managed by the I-DHU.


  • 26

Figure 16. Overview of the I-DHU operation modes and transitions


I-DHU Resources and temperature

The masses reported in this page are extracted from the CAD-models and part files for the PCBs. The latter are at this point in time only rough estimations and based on values from similar previous designs. The harness assumes a length of 1 m for all cables. Depending on the location of the I-DHU, the values need to be scaled accordingly. The resources to be allocated for each I-DHU are summarized in Table 5 while Table 6 reports the temperature ranges.


Table 5. I-DHU resources allocation summary

Mass [kg]


Volume [mm3]


Power [Watt]



Table 6. I-DHU Temperature Range

Temperature Range

Min. [°C]


Operative Temperature



No-Operative Temperature