1 Introduction

Prior to the BepiColombo mission, two NASA missions had investigated Mercury: Mariner 10 and MESSENGER (cf. Balogh et al. 2007). Mariner 10 executed three flyby observations in 1974–1975, revealing the face of the innermost planet for the first time and discovering its intrinsic magnetic field and magnetosphere. MESSENGER (cf. Solomon et al. 2007) became the first orbiter of Mercury in 2011–2015, providing new information by orbiting its periapsis in the northern hemisphere.

BepiColombo will be the third and the most advanced project (cf. Benkhoff et al. 2010, 2020, this issue). It was launched on 20 October 2018, from Kourou as the first joint planetary mission between the European Space Agency (ESA) and the Japan Aerospace Exploration Agency (JAXA), and consists of two spacecraft with different orbit and altitude-control systems. ESA’s Mercury Planetary Orbiter (MPO) is a three-axis-stabilized spacecraft with 11 payloads that are mainly focused on the surface and interior of Mercury. JAXA’s Mio, also known as the Mercury Magnetosphere Orbiter (MMO), is a spin-stabilized spacecraft with five payload groups that will mainly investigate the Hermean environment (Hayakawa et al. 2004; Yamakawa et al. 2008; Murakami et al. 2020a, this issue). During the long space cruise, which includes multiple flybys of Earth, Venus, and Mercury, the Mio spacecraft is combined with the MPO and the Mercury Transfer Module (MTM) as part of its cruise configuration. At the end of 2025, after 7.8 years of cruising, the spacecraft will become the second and third spacecraft to orbit Mercury. On polar orbits (MPO: 480 × 1,500 km; Mio: 590 × 11,639 km), their combined observations will maximize the comprehensive view of Mercury, including precise determination and separation of the planetary and environmental magnetic fields (cf. Milillo et al. 2010, 2020, this issue).

The Mio design covers four main scientific targets for advanced comparative studies of terrestrial planets: (1) the structure and origin of Mercury’s magnetic field; (2) the structure, dynamics, and physical processes in Mercury’s magnetosphere; (3) the structure, variation, and origin of Mercury’s exosphere; and (4) the inner heliosphere. The Mio spacecraft consists of a platform spinning once every 4–5 s, which is optimized for the first detailed study of the magnetic field, waves, and particle environment of Mercury. Its five payload groups were selected in 2005 (Mukai et al. 2006). Three of these payload groups will perform in situ and remote measurements of the magnetosphere, exosphere, and solar wind environments, these being the MaGnetic Field Investigation (MGF), with two independent sensors (Baumjohann et al. 2010, 2020, this issue), the Mercury Plasma Particle Experiment (MPPE) for plasma and neutral particles with seven sub-instruments (Saito et al. 2010, 2020, this issue), and the Plasma Wave Investigation (PWI) for electric fields, plasma waves, and radio waves with seven sub-instruments (Kasaba et al. 2010, 2020, this issue). The remaining two payload groups have independent tasks: the Mercury Sodium Atmosphere Spectral Imager (MSASI) is responsible for remote-sensing study of the sodium exosphere (Yoshikawa et al. 2010; Murakami et al. 2020b, this issue) and the Mercury Dust Monitor (MDM) covers the dust information around Mercury and the inner heliosphere (Nogami et al. 2010; Kobayashi et al. 2020, this issue).

To fulfill the scientific objectives subject to restriction of spacecraft resources, all payload groups of the Mio spacecraft are connected to, and controlled through, the Mission Data Processor (MDP) for unified telemetry production with coordinated observational modes and time resolutions. The MDP not only enables us to reduce the mass, power, and telemetry of the Mio spacecraft, but also ensures the scientific operation of the Mio as an integrated system for Hermean environmental studies through in situ observation of charged and energetic neutral particles, magnetic and electric fields, plasma waves, dust, and the remote sensing of radio waves and exospheric emissions. In combination with the MPO, the Mio will fully observe the unique environment of Mercury, which is characterized by weak intrinsic magnetic fields, strong solar illumination, and solar wind with high dynamic pressure.

2 MDP Specifications

Mio’s scientific operation is restricted by the telemetry bandwidth to the ground. The raw-data rate from all payloads is over 8.5 Mbps (Table 1), which are mainly from MPPE (particle energy and counts), PWI (waveforms and spectrum), and MSASI (imaging). However, the telemetry bandwidth to the ground is only up to 32 kbps, depending on the distance between Earth and Mercury. It is also limited by the operational time of the ground station, the JAXA Misasa Deep Space Center. Therefore, the expected telemetry rate is 4 kbps (or less) on average, which is much less than the raw-data rate from all payloads. Moreover, the thermal harshness of the spacecraft also limits its operation. In the phase close to perihelion, the base temperature inside the spacecraft is close to 60°C at the periherm, necessitating frequent and synchronous power-off or standby modes for all payloads.

Table 1 A summary of the scientific telemetry from each payload. The raw-data rate produced from each payload to the MDP (kbps), the storage size in the DPU-DS (min) for each payload, and the planned averaged rates in the Survey (L) and Nominal (M) from the MDP to the DMC-DR after data compression are shown. The L- and M-mode values are averages seen during the Mio system FM test on the ground. The compression ratio would be worse in the real observations. The Raw column shows acceptable values in the MDP design and are larger than real values in some payloads
Full size table

In order to maximize the scientific output and flexibility of all operations, all data communications to and from the payloads are channeled through the MDP, which is also responsible for coordinating and integrating the observations and data production of all payloads. The MDP provides telecommand (CMD), housekeeping (HK), and telemetry (TLM) interfaces to all five payload groups on the Mio spacecraft. This MDP scheme is based on the concept outlined below, which specifies not only the design requirements of the spacecraft, but also the role of the scientists on the ground. The effort and capability of the scientists examining the data in quasi–real time are vital.

  1. (1)

    For the integrated controls, CMDs to each payload are sent from the Data Management Controller (DMC) as well as the MDP. The MDP can also create sequences of CMDs to the payloads triggered by the CMDs sent to the MDP, or by specific HK conditions of the payloads identified by the MDP.

  2. (2)

    For integrated status monitoring, the HK data from each payload is monitored by the MDP. HK data is sent from all payloads through the MDP to the DMC, where it is stored in the System Data Recorder (DR). The MDP sends not only the raw hardware HK from the payloads, but also the integrated HK created in the MDP, including the software status.

  3. (3)

    For the integrated telemetry production, scientific TLM data from each payload is accumulated by the MDP in as raw of a fixed format as possible. The MDP keeps these datasets inside its own data storage for sufficient lengths of time. For synchronization of related instruments, the MDP creates the scientific telemetry from the raw data stored in internal storage and sends it to the DR. Three kinds of TLM datasets are created; a Survey (L) mode for continuous monitoring, a Nominal (M) mode for standard analyses of several hours (or more) in length, and a Burst (H) mode for high-quality analysis based on 4–20 min interval data sets. H-mode data is taken at preset timings, or by onboard automatic triggering.

  4. (4)

    Onboard data is produced by the software developed, implemented, and tested by the primary-investigator (PI) teams (MGF, MPPE, PWI, MDM, and MSASI) and the MDP team in order to ensure flexibility and maintenance until the completion of the mission.

  5. (5)

    L-mode data is downloaded to the ground. In order to utilize the limited telemetry bandwidth, M and H-mode datasets are partially downloaded to the ground, where they are checked by a team of scientists against L- or L/M-mode data, respectively.

Based on this concept, the raw data transferred from the payloads is converted into three categories of reduced-telemetry data by the MDP software, which is directly managed by the PI team members. Under the limited telecommunication bandwidth, the telemetry design is critical for maximizing the scientific output of the mission.

3 MDP Design

The MDP is installed inside the Mio spacecraft on the lower deck. Figure 1 shows the outer shape. It is an electronics box with a size of \(114 \times 253 \times 171\) mm, a mass of 2,360 g, and a power consumption of 13.4 W in nominal operation modes. Its design was originally based on the Mission Data Processor aboard the JAXA Hinode solar space telescope (Kosugi et al. 2007), but it was modified according to the mission requirements of the BepiColombo project, specifically the coordinated treatment of 16-ch data sets from multiple payloads with sufficient flexibility to last the mission (approximately 25 years).

Fig. 1
figure 1

Outer shape of the MDP when shipped to the system in 2012

Full size image

The configuration of the data connection in the Mio spacecraft is summarized in Fig. 2. In the Mio spacecraft, the DMC handles all CMDs and HK/TLM data transfers from and to the ground. In the cruise configuration, the Mio receives and sends them through the MPO spacecraft with limited bandwidth. The DMC also has a DR (size: 2 GB) for the storage of HK and TLM data.

Fig. 2
figure 2

Simplified block diagram of the data connection in the Mio spacecraft based on the MDP scheme. The thick lines represent the digital-communication lines for CMDs and HKs/TLMs. The thin lines represent the analog-signal lines. The thin dotted lines represent the deployment-drive lines. The DR is inside the DMC unit. DPU1 and DPU2 are inside the MDP chassis. The MGF and PWI receiver units are inside the PME chassis. The MGF sensors are on the MAST-MGF boom. The PWI LF/DB-SC sensors are on the MAST-SC boom. The deployment of two MAST booms and the two WPT sensors is controlled by the MAST-WPT-E inside the PME chassis. The deployment of the two MEFISTO sensors is controlled by the MEFISTO receiver in the PME chassis

Full size image

For integrated operations and data production with limited mass, power, and telecommunications bandwidth, the MDP is designed to integrate the data stream between the DMC and all payloads. The MDP has two Digital Processing Units (DPUs), which are independently powered by Power Supply Units (MDP–PSU1 and MDP–PSU2). DPU1 and DPU2 are independently connected to the DMC via 2-ch SpaceWire (SpW) links with an 8-MHz clock, which are based on the IEEE-1394 (FireWire) serial-link technology with the Remote Memory Access (RMAP) protocol (cf. Parkes and Armbruster 2010; ESA 2008, 2010). Through these links, the CMD and HK/TLM are sent between DMC and each DPU. The DPUs are also connected to each other by a single 12 MHz SpW link, which enables data sharing with respect to onboard triggering in the H-mode activation (see Sect. 5.3). This connection also provides a redundant route for a failure at any one of the DMC–DPU I/F, DPU1–CPU, or DPU2–CPU (CPU: Central Processing Unit).

Each DPU has 8 SpW I/F connections to the payload units. DPU1 has SpW I/F connections to MPPE (MEA1, MEA2, MIA, MSA, HEP-ele, HEP-ion, and ENA) and one to MGF-Outboard. DPU2 has SpW I/F connections to MGF-Inboard and PWI. These include two lines for EWO with AM2P, SORBET, and MEFISTO, including the deployment controller of two MEFISTO wire antennas, as well as connections with MSASI, MDM, and MAST-WPT-E (the deployment controller electronics of the MAST–MGF boom [for MGF-Inboard/Outboard sensors], the MAST–SC boom [for PWI SC–LF and SC–DB], and two WPT-S wire antennas [for PWI]). In order to reduce the power of each payload, these connections use a 1.98–4.40 MHz link, which is less than the standard SpW link definition (10 MHz). Through these links, CMD and HK/TLM are sent between the DPU and each unit.

Both DPUs have identical hardware designs. Figure 3 shows a simplified block diagram of the hardware-level data connection in the MDP DPU. The hardware is designed, manufactured, and tested by Mitsubishi Heavy Industry (MHI). Each DPU has one CPU, JAXA/HIREC-MIPS-HR5000 (clock: 24 MHz, CPU core: 96 MHz), with a work area of 2 MB by SRAM and a program-storage area of 1 MB by EEPROM. The program stored in EEPROM can be rewritten partially from the ground. Additionally, each DPU has two FPGAs (RTAX2000SL), one for the DMC I/F controls and the other for the payload I/F controls. The DPU also has Data Storage (DS, 256 MB by SDRAM), which forms multiple ring buffers to store raw data sent from the payload. In this design, the CMD and HK between the DMC and payloads can be directly transferred through the DMC I/F FPGA and payload I/F FPGA without the CPU. The CPU can receive the CMD from the DMC and create CMDs to the payloads. The CPU can also see the HK from the payloads and create higher-level HK, including the software status. The scientific TLM data from the payloads are stored in the ring buffers of the DS with the time length summarized in Table 1. The CPU reduces these elements, creates the TLM stream in the L/M/H-mode with hardware/software compression, and stores them in the DR of the DMC.

Fig. 3
figure 3

Simplified block diagram of the hardware-level data connection in the MDP DPU. DPU1 and DPU2 have identical designs. The CMD and HK between the DMC and the payloads can be directly transferred through the DMC I/F FPGA and payload I/F FPGA without the CPU. The CPU can receive the CMD from the DMC and create CMDs to the payloads. The CPU can also see the HK from the payloads and create higher-level HK, including the software status. The scientific TLM data from the payloads are stored in the ring buffers of the DS with the time length summarized in Table 1. The CPU reduces these elements, creates the TLM stream in the L/M/H-mode with hardware/software compressions, and stores them in the DR of the DMC

Full size image

The MDP functions are also implemented by the software, which is identical in each DPU, but operates in slightly different ways. Figure 4 shows the software structures in each DPU. The operating system (OS), firmware, and middleware are procured by the MHI. Core tasks are designed, manufactured, and tested by the MDP team (Tohoku University + JAXA). PI tasks are procured by the MPPE, PWI, and MGF teams and the MDP team (for MSASI and MDM).

Fig. 4
figure 4

Software structures in each DPU

Full size image

With the T-kernel OS (a real-time OS, modified by eSOL Co., Ltd. and procured from JAXA), the firmware and middleware (designed, developed, and tested by MHI) handle the hardware access and achieve integrated control and data reduction of the payloads. Core tasks are designed, developed, and tested by the MDP team, and access to the lower layers is granted through the Application Program I/F (API) in order to serve the common infrastructure for PI tasks. Each task controls specific CMD/HK/TLM functions for each payload unit. Some coordinated data reductions and triggering actions are also implemented; sorting along the magnetic field for MPPE, and waveform acquisition with dust hits detected by MDM for PWI.

The MDP provides CMDs to and receives HK data from each payload unit every second. These data consist of three categories outlined below:

  1. (1)

    CMD/HK from/to the DMC to/from the MDP hardware: handled by the MDP FPGAs. Even when the CPU is off, these can still be received and executed. However, when the CPU is off, the CMD/HK of PI instruments cannot be transported.

  2. (2)

    CMD/HK from/to the DMC to/from the payloads: handled by the middleware on the CPU. Even when the PI tasks on the CPU are disabled, CMD/HK can still be directly transported between the payloads and DMC.

  3. (3)

    CMD/HK from/to the DMC to/from the MDP core and PI tasks: handled by the MDP applications run by the corresponding tasks on the CPU.

All tasks can obtain CMDs and send HKs; moreover, they can also send CMDs to payloads, edit HK packets, and create TLM packets. In other words, they enable us to decode HK data from the payloads, automatically create CMD sequences according to the payload status, and conduct-coordinated and synchronized operation of multiple instruments (for example, antenna deployment) and emergent reactions (for example, latch-up detection). Some elements of these hardware and software designs are also adopted in the CPU board in the Arase spacecraft and are performed well (cf. Kasahara et al. 2018; Matsuda et al. 2018).

DPU1 or DPU2 can activate redundant functions for the failed-side DPU when the payload I/F FPGAs in both DPU1 and DPU2 survive. This is expected in the following two cases: (1) when the DMC I/F FPGA, connector, or harness of DPU1 or DPU2 fails, or (2) when the CPU in DPU1 or DPU2 fails. Through the DPU–DPU SpW I/F, the surviving DPU (master) can handle all communications to the payloads that are normally handled by the failed DPU (slave) via the payload I/F FPGA of the failed DPU. We note the limitation of the CPU-load capability: although the DPU2-fail case can almost execute full functions, the DPU1-fail case can only maintain the MGF-Outboard and ENA functions with some limited MPPE functions. In this case, CMDs and HKs can still survive, but it is hard to produce the TLM stream from the majority of MPPE instruments.

In order to achieve these functions as quasi-real-time operations, the core and PI tasks are divided into five layers with different priorities. The layer definitions are listed below in order of their task priorities:

  1. (1)

    [Layer-1: CMD tasks (0.125-s interval)] These receive and execute the CMDs from the DMC, creating CMD sequences and sending them to the payloads.

  2. (2)

    [Layer-2: HK tasks (1-s interval)] These read the HKs from the payloads, creating an integrated HK packet and sending it to the DR.

  3. (3)

    [Layer-3: L/M-mode tasks #1 (one spacecraft spin (4–5 s) interval)] These read the latest raw datasets from the payloads in the DPU–DS, creating L and M-mode TLM packets and sending them to the DR as real-time data for MPPE, except for ENA, MGF, PWI, and MDM.

  4. (4)

    [Layer-4: L/M-mode tasks #2 (one spacecraft spin interval)] These are similar to Layer-3, but with a lower priority for quasi-real-time data streaming for MPPE-ENA and MSASI, which sometimes exceeds the time limit of one spin. A PWI-calibration sequence is also included.

  5. (5)

    [Layer-5: H-mode tasks (background)] During H-mode activation, these slowly read the raw data stored in the DPU–DS, creating the H-mode TLM packets and sending them to the DR as background non-real-time data reproduction for MPPE, except for ENA, MGF, and PWI-EWO.

4 Scientific Data Flow in the Mio Spacecraft with the MDP

DPU1 and DPU2 continuously receive a raw data stream from all payloads, which has an almost fixed format and a constant rate (Table 1). The raw data for each payload is stored in the ring buffer of the DPU–DS. The PI tasks perform data-reduction tasks using the stored data at an interval of once per spacecraft spin (4–5 s), such as sorting along the magnetic field (MPPE), fast Fourier transform (FFT) for the conversion from waveform to spectrum (PWI), time averaging, and data compression (commonly adopted for all data sets). The data stored in the DPU–DS are also used for H-mode TLM production of the in situ observations by MPPE (except ENA), MGF, and PWI/EWO. For this objective, the ring buffers of the DPU–DS keep data with time lengths of 20 min for MEA-1/2, MIA, MSA, HEP-ele/ion, MGF-out/in, and EWO-EFD, as well as data with time lengths of 4 min for EWO-E/B. When these long buffers are in ‘nonwriting status’ during the H-mode data dump, short buffers with time lengths of 20 s are used for L and M-mode TLM production. Note that ENA, SORBET, MDM, and MSASI do not have an H-mode.

After data reduction, the MDP stores the processed data telemetry in the DR. L and M-mode datasets are continuously produced as a stream and sent to the DR, whose rate is summarized in Table 1. The H-mode data is sometimes dumped from the data stored in the DPU–DS, with the aforementioned time lengths (20 min max for MEA-1/2, MIA, MSA, HEP-ele/ion, MGF-out/in, and EWO-EFD; 4 min max for EWO-E/B). In order to store these data, we divided the DR into multiple partitions organized as ring buffers for the L, M, and H-modes. For each payload unit, the DR has one partition with a length of 9 days for the L-mode and 8.6 days for the M-mode. The DR also has five partitions with 4–20 min lengths for the H-mode (Table 2).

Table 2 Lengths of the 12 DMC-DR partitions for payload-data storage, separated according to the download policy. The L-mode data are dumped within the one-week limit. M and H-mode datasets are partially dumped after selection. For L and M-mode datasets, the time length of the storage area is based on the data rate summarized in Table 1. If the data rates are high because of a low compression efficiency, the time length of storage becomes shorter
Full size table

To reduce the data rate, the DPU provides two lossless compression functions in the common library, which are based on an arithmetic-coding algorithm implemented in the core-task software and lossless compression using Differential Pulse Code Modulation (DPCM) algorithm implemented in the payload I/F FPGA. Two other algorithms are also implemented in the PI tasks. The first algorithm is the Rice algorithm (cf. Rice et al. 1993) by MPPE, with lossless compression for data in which most values are close to zero. The second algorithm is a waveform-compression algorithm by PWI, with lossy compression with sub-band coding, which is based on the same algorithm used in the Plasma Wave Experiment (PWE)-WFC aboard the Arase spacecraft (Kasahara et al. 2018; Matsuda et al. 2018).

5 Data Dumped to the Ground

In the mission design, most of the scientific tasks carried out on the Mio spacecraft should be performed with the L and M-mode data sets, as the H-mode is intended for special objectives. Each mode is outlined below.

  1. (1)

    For the L-mode, all data is downlinked according to the highest priority as fast as possible within three to four days of the observations. This data is used for the download plan of the M-mode/H-mode data.

  2. (2)

    For the M-mode, a team of scientists check the L-mode data based on the shared objectives from the observation plan. Based on the decisions made here, M-mode partitions are partially downloaded. These decisions should be made at least once a week, before the M-mode data in the DR is overwritten.

  3. (3)

    For the H-mode, when the telecommunication bandwidth is sufficiently large to accept an additional dump, one of the H-mode partitions is partially dumped according to the L and M-mode data. This decision is also made by the aforementioned scientific team.

For the in situ instruments, we will fulfill Mio’s scientific targets (Sect. 1) with L-mode data for (1) and by L-mode/M-mode data for (2)/(3)/(4). The H-mode data with the highest quality and time-resolution will also add special outcomes for which electromagnetic waveforms, three-dimensional energy distribution functions of particles, and a detailed view of the transient features associated with short and variable events such as boundary transfers and energetic events are required.

During the cruise phase, the Mio spacecraft is connected to the MPO. In this configuration, the Mio can only produce L-mode data. As an exception, during flyby operations, the MDP can produce a special-mode data, including partial M-mode data in addition to L-mode data.

5.1 L-mode data

L-mode data is produced from all payloads. This data is used for continuous monitoring of the averaged and/or macroscopic characteristics of the Hermean environment. L-mode data is also used for decisions involved in the M-mode/H-mode data-dump plan.

The MPPE-ENA (flux of energetic neutral atoms as remote sensing) and MDM (dust count) have relatively low data rates, and can only produce data in this mode.

Other payloads provide monitoring data with lower resolutions in time, energy, spectrum, and other metrics: MPPE produces density, velocity, temperature, and energy spectra in 1 to 4 spacecraft spins. MGF produces a B-field vector in 1 spacecraft spin. PWI produces the 1-Hz spacecraft potential, 4-Hz E-field waveform, and 2–40-Hz E-field spectrum in 4 spacecraft spins, the 10-Hz to 20/120-kHz E-field and 10-Hz to 6/20-kHz B-field low-resolution spectra in 4 to 8 spacecraft spins, the 100-kHz to 10-MHz E-field (and 100–360-kHz B-field) low-resolution spectrum in 10 (or 5) spacecraft spins, and the passive/active electron-density/temperature indices. MSASI produces low-resolution sodium-emission images.

5.2 M-Mode Data

M-mode data is produced from the MPPE (except for ENA), MGF, PWI, and MSASI. It is designed to have sufficient quality in terms of standard intensive analyses for the mission objectives. M-mode data is also used to select the H-mode data dump.

For the M-mode data-dump plan, quasi-real-time selection is conducted by a team of scientists, who check the L-mode data. For payloads with M-mode data, this action will be key for achieving the mission objectives. Although only partial amounts of data can be dumped, we flexibly select data with specific continuous time lengths from those continuously stored in the DR. For example, when we dump 20% of the M-mode data, we can select ‘1/5 (2 h) of each orbit (∼8 h)’ or ‘one of five orbits’. Other scenarios are also possible.

Under these restrictions, we can investigate issues that require higher resolutions and qualities than L-mode data, such as special kinematics and non-magnetohydrodynamic (MHD) features expected around Mercury, the structures and processes of various regions (shocks, magnetopause, auroral regions, cusps, plasma sheets), and time variations over short-to-medium scales. For these objectives, payloads providing M-mode data create higher resolutions with respect to time, energy, and spectral resolution compared to the L-mode: MPPE produces moment, energy-spectrum, and 3D distributions in 0.5 to 4 spins. MGF produces 8 or 4-Hz B-field waveforms. PWI produces 8-Hz spacecraft potential, 8-Hz E-field waveforms, 2–40-Hz E-field spectra, and 10-Hz to 20/120-kHz E-field and 10-Hz to 6/20-kHz B-field high-resolution spectra from 0.5 to 4 spins, as well as 2.5-kHz to 10-MHz E-field and 2.5–640-kHz B-field high-resolution spectra with passive electron density/temperature in 1 to 2 spins. MSASI produces high-resolution images.

5.3 H-Mode Data

H-mode data are produced by the MPPE (except for the ENA), MGF, and PWI-EWO. According to the description in Sect. 4, the DPU–DS always stores raw data in 4–20-min intervals. By the CMDs or the onboard data-triggering function, this data can be held without being overwritten and then copied to the H-mode partitions in the DR. Afterwards, some of these datasets can be partially dumped to the ground based on the decisions of the aforementioned team of scientists looking at Survey and Nominal-mode data. Accordingly, we can potentially obtain short periods of raw data (less than 4–20 min, restricted by the size of the DPU–DS). This data length is still long enough to cover the major boundaries and events expected in the Hermean environment. Moreover, although the EWO waveform data in the E and B-fields is short in length, it can cover the last 4 min of the longer data interval. In order to operate the Mio spacecraft as an integrated Hermean-environment surveyor, a dataset covering all payloads is essential for integrated analysis. Therefore, this last 4-min duration is the core of the H-mode datasets.

These datasets are simultaneously captured and stored in the DPU–DS, and sent to one of the H-mode partitions (H1–H5) in the DR. For example, when we obtain the data in and around the plasma sheet, we set this trigger command before the Mio reaches the magnetic equatorial region. From each of the five H-mode datasets in the DR, some parts will be selected and dumped.

The H-mode data-acquisition method is similar to that of the Arase spacecraft (cf. Kasahara et al. 2018; Matsuda et al. 2018). Two methods exist: the preset CMD-triggering scheme and the onboard automatic-triggering scheme. Both schemes can obtain data before and after the trigger within a length of 4–20 min at maximum.

In the first method, the acquisition of H-mode data is executed by a CMD (TLMH_DUMP in Table 3) in the preplanned sequence at a specific time defined in advance by the scientific objectives and operational phases.

Table 3 MDP operation commands for the data acquisition of the H-mode. The values in the table are hexadecimal. TLMH_DUMP executes data acquisition at the timing of CMD. TLMH_TRG_SET is set according to the conditions of the onboard triggering system MATRIX. TLMH_TRG_STRT executes, stops, or resets the MATRIX function. The parameters used in TLMH_TRG_SET are summarized in Table 4
Full size table

The second method can set flexible acquisition timings. For this objective, MDP Automatic TRIgger compleX system (MATRIX) system is implemented in the core task. A part of the event triggering concept is referred to as the THEMIS design (Taylor et al. 2008). And the similar design is implemented in the Arase PWE onboard system (Matsuda et al. 2018). Table 4 summarizes the parameters that can be used in the onboard triggering, these being the magnetic field (MGF), particles (MPPE), electric field, plasma waves, and radio waves (PWI). These parameters are created in the MDP from raw data in the DPU–DS according to each spin (4–5 s). According to the trigger-decision logic, a maximum of four parameters can be used from this list that are preset by two CMDs in Table 3 (TLMH_TRG_SET for setting the parameters and TLMH_TRG_STRT for starting, stopping, and resetting the system). If the absolute (or differential) values of the triggering parameters simultaneously exceed the threshold levels preset in the parameter table, the MATRIX system activates automatic triggering as a preset H-mode command. The score used in each triggered dataset is stored, and the highest-scoring data can overwrite data with a lower score stored in the DR.

Table 4 Parameters used in the onboard automatic trigger system MATRIX for the acquisition of Burst mode (H) data. This data is obtained by the PI tasks from the raw data stored in the DPU-DS with the arbitral unit set as once per spin. The data can be dumped to the ground
Full size table

We should note that tuning the parameters of the onboard triggering system is not an easy task. Although the automatic-triggering case can store a maximum of five events, trial-and-error actions will be required during the first year of observation.

5.4 Duty Ratio of L, M, and H-Data

Figure 5 shows an operational example of L, M, and H-modes around Mercury. At the aphelion with the dayside periherm (the top of Fig. 5), the Mio mostly stays in the nightside magnetosphere and along the magnetopause. Here the L-mode continuously stores the data in the DR. The M-mode also continuously stores the data. And a section of these data with a length of several hours is dumped. We try to pick up these data covering the key regions selected according to scientific motivations. At the perihelion with the nightside periherm (the bottom of Fig. 5), the Mio spacecraft mostly stays in the solar wind. The L-mode records the majority of data here, while the M-mode covers data associated with shocks, magnetopauses, the cusp, and/or the nightside region for several hours. For all cases, the H-mode sometimes takes data in 4–20 min intervals when the M-mode dump is being planned. Since the Hermean environment has a smaller size and a shorter time scale than the terrestrial one, the time lengths of the M and H-modes are limited but still can catch many key science issues. The MDP also produces the packets outlined below as common definitions of all payload data streams.

  1. (1)

    Usual HK packets for all systems: arbitral intervals based upon operational demands.

  2. (2)

    MDP User-HK packets (as part of HK): once per 256 s in nominal operation, which can be made higher on demands. These are created by the PI tasks in the MDP.

  3. (3)

    MDP trigger-data packets (as part of L-mode/M-mode data): once per 16 spins. These are the H-mode trigger parameters for the MATRIX system (see Table 4), which are used to tune parameters to achieve proper onboard-triggering conditions.

Fig. 5
figure 5

Operational images of the Survey (L), Nominal (M), and Burst (H) modes on the Mercury orbit. Top: at the aphelion with the apoherm at the nightside. Bottom: at the perihelion with the apoherm at the dayside. The time after the apoherm is also shown (orbital period: 9.3 h) with an expected magnetospheric location. Under real operation, the M-mode is continuously stored in the DR and partially downloaded to the ground after selection. The H-mode can be stored at any location at specific and limited timings; it can be downloaded to the ground after selection

Full size image

Moreover, the downlink policy outlined below ensures a telemetry limitation of 4 kbps or less:

  1. (a)

    L-mode data is potentially downlinked with approximately 25% of the averaged telemetry bandwidth.

  2. (b)

    Portions of the M-mode data (25% or less) are dumped to the ground with approximately 50% of the averaged telemetry bandwidth.

  3. (c)

    H-mode data is dumped in the highest-link phase (32 kbps) when Mercury is close to Earth, with approximately 25% of the averaged telemetry bandwidth.

Prior to launch, we assumed the plan outlined below:

  1. (1)

    For the L-mode, the downlink speed to the ground is approximately 1.5 kbps (16 MB/day). All L-mode data taken on the spacecraft will be downloaded.

  2. (2)

    For the M-mode, we assume approximately 25% selection during operation. Accordingly, the averaged downlink rate becomes 14.8 kbps × 0.25 = ∼3.7 kbps (40 MB/day).

  3. (3)

    For the H-mode, roughly 1.5 kbps (16 MB/day) is considered when the telemetry rate is sufficiently high.

Including an HK-TLM value of approximately 0.15 kbps, the total averaged telemetry rate requires approximately 6.85 kbps (74 MB/day) when the MDP and payloads are turned on. In the current operational plan around Mercury, the expected power-on time will be limited by approximately 60% because of the harsh thermal conditions (Murakami et al. 2020a, this issue). Therefore, the realistic data rates from the Mio spacecraft will be approximately 4 kbps (43 MB/day) on average.

This plan can be affected by many factors; spacecraft thermal conditions, telecommunication conditions (including ground-support schemes), the DR status, and the actual compression ratio of the telemetry. Therefore, it will be updated according to the real operational plan and spacecraft conditions during the cruise phase and the operation around Mercury in the first Hermean year.

6 Summary

The functions and performances of the MDP described in this paper were carefully tested with all payloads during the Mio system Flight Model (FM) test campaign at ISAS/JAXA until 2015, the BepiColombo system FM test campaign at ESA/ESTEC, and the launch campaign at Kourou. After the launch, although the full functions cannot be currently used, the MDP performed well with all payloads during commissioning tests. Currently, we are preparing scientific operations for one Earth flyby (10 April 2020 in the latest plan), two Venus flybys (15 October 2020 in the latest plan, and August 2021), six Mercury flybys (October 2021; June 2022; June 2023; September 2024; December 2024; and January 2025), and Mercury orbit insertion (December 2025). This paper has summarized the information that will be used for the operational and scientific work required.

MESSENGER obtained multiple new views of Mercury, all of which have impacted the observation plan of BepiColombo. The design and scientific operation of the Mio spacecraft are based on the flexible MDP scheme described in this paper and will stand in changes and demands expected in future. The full observation at Mercury will not take place until the end of 2025, but we are convinced of our success in the future.