The MDP-E consists of two mission data processor boards (MDP1 and MDP2), mission data recorder boards (MDR1 and MDR2), and power distribution units (PDUs). The dimensions of the MDP-E are 165 mm × 265 mm × 167 mm, its mass is 4.25 kg, and its power consumption is 29.8 W. The MDP-E has two SpaceWire ports connected to the router in the bus network. The MDP is the only component connecting the bus and the mission network, and two MDPs have been provided for redundancy in case of a breakdown. This allows for single-system failure faults caused by the small satellite project; however, it constitutes a redundant system for parts that are entirely damaged by the mission and for parts necessary for gathering information on failure causes. Therefore, the data communication line with SpaceWire, the power supply line, and the spin index pulse line all have redundant systems to avoid whole mission failure when there is a fault at an interface point between the bus and the mission.
Power line between the bus and the mission
Power lines from the bus module are shown in Fig. 3. Two power supplies from the bus are connected independently to MDP 1 and MDP 2, and the remaining two are used as the power supply for the eight scientific instruments. The power is supplied to the instruments via a switch with an overcurrent breaker from the PDUs inside the MDP-E. In the power switch part, a circuit breaker is arranged in each switch, and when a short failure occurs on the downstream equipment side, the circuit breaker operates before the current limiter in the upstream bus side. It is designed to isolate the faulty power line in the mission unit. Each switch is turned on/off by a command to the MDP. The control signals are connected to this switch from both the MDP 1 and MDP 2 such that the instrument power switch can be controlled even when an MDP system failure occurs. This is a redundant configuration. The power switch in the PDU adopts the field effect transistor switch (FET-SW), and, in emergency cases, it turns off the MDP power supply from the bus automatically as a safety design.
The interface component, the “MDP,” between the bus network and the mission network
The interface between the bus network and the mission network: the “bridge connection”
Command and telemetry data between each component in the mission module and bus system are implemented by the SpaceWire remote memory access protocol (RMAP) (ECSS-E-ST-50-52C 2010). In the SpaceWire network, point-to-point communication is generally performed by connecting a plurality of components via a router. In Arase, however, the SpaceWire network in the bus section and the SpaceWire network in the mission section are not directly connected by router.
The Arase mission module contains the system that separates the mission network from the bus network and bridges the data packets in both directions in the MDP’s internal processing. The reasons for making a bridge connection rather than a routing connection are as follows.
-
a.
Since a large number of science data packets always flows from the instruments through the mission network, it would be difficult to limit and control the bandwidth with the bus component data if all mission packets flowed in the bus network. In addition, when a mission packet transmission runaway or the like occurs in a mission instrument, the possibility of the satellite falling into a critical state is influenced by the bus network. Therefore, we use the bridge connection with the bus network to avoid the possibility.
-
b.
The instruments operate based on the observation sequence of the spin index pulse, which indicates the start time of spin by the sun sensors. The sun index pulse transmits the timing to the instruments using the TimeCode function, which acts as the system function in SpaceWire (similar broadcast packet to all nodes). As such, there is no dedicated harness to send the sun index pulse to each instrument. In the bus network, the setting and usage method of this TimeCode function is stipulated, and it was impossible to install the spin index pulse function of the mission network.
Therefore, by separating the network of the bus and the mission, the bridge connection can be employed so that the TimeCode method can be arranged in a different manner for the bus and the mission.
“Ring network” with SpaceWire in the mission
In the mission data processing system, SpaceWire has been adopted and utilized to facilitate communication between each component. As for the physical connection, the SpaceWire connection on the ring, shown in Fig. 4, is adopted, in consideration of the cable resources, SpaceWire router system, and communication redundancy, by securing a detour path for the communications. Multiple connections from the ring to MDP 1 and MDP 2 on the inner side are evacuation routes when an anomaly occurs in the regular communication path. For packet transmission and reception at the mission network, the path-address function is adopted for RMAP communications. To enable the route of a packet to be changed when an anomaly occurs in the network, a path-address function is adopted in which the transmission path information is embedded in each packet. In Fig. 4, when the low-energy particle experiment ion analyzer (LEP-i) sends a packet to MDP1 through the RMAP write protocol, the path-address information defined as “CPU5,” “CPU6,” “CPU7” (CPU: Central Processing Unit), and “MDP1” is embedded in the packet. Since there are multiple routes between each component and the MDP, it is designed to cope with network failures. For example, when there are two access routes from the high-energy electron experiment (HEP) to MDP-1, a nominal route path is defined by the onboard software code in the mission network. This is demonstrated in Fig. 4, in which one route from the HEP to MDP-1 is via the medium-energy particle experiment electron analyzer (MEP-e), and the other is the route via the extremely high-energy electron experiment (XEP).
“Relay packet” in the mission network
We used the new “relay packet,” optimized for the ring network of the Arase mission module, to deliver commands to the instrument, act as an instrument housekeeping (HK), and exchange shared data between instruments. This relay packet also monitors the health of the mission network.
The outline of new “relay packet” transmission in the mission network is explained below.
-
The packet size of the relay packet is constant.
-
The relay packets periodically travel, as one is released every second, around all instruments.
-
The same packet is transmitted twice consecutively as a countermeasure against a temporary SpaceWire link down (e.g., electrical noise) (retransmission control)
-
To confirm the receipt of the relay packet, the instrument receiving the relay packet marks its own ID in the relay packet.
A conceptual diagram of the relay packet transmission is shown in Fig. 5. In the relay packet, MDP1 is the starting point and MDP2 is the ending point, and they are delivered to all instruments constituting the mission ring network abound for the clock direction. The route is MDP1, XEP, MEP-i, MGF-E (MaGnetic Field Experiment), PWE-E#1 (Plasma Wave Experiment), PWE-E#2, LEPs, MEP-e, HEP, and MDP2. Upon receiving the relay packet, each instrument updates the relay packet in the next time slot (explained below) that is synchronous with the TimeCode in the mission networks and transmits it to the next instrument. If one of the relay packets is transmitted twice in succession by the retransmission control, the relay packet is transmitted to the next instrument along the normal path. However, if because of some anomaly, neither relay packet can be received, the transmission to the anomalous instrument is skipped, and a relay packet is transmitted to the next instrument ahead to change the path direction to the opposite direction. For example, if the path between the LEP-i and the MEP-e is broken, the LEP-i changes the direction of the relay packet to the opposite direction. The LEP-i sends the relay packet to the MEP-e through the path including the PWEs, MGF-E, MEP-i, XEP, HEP, and the MEP-e. After the MEP-e, the relay packet is sent to MDP2 via the normal path that contains the MEP-e, HEP, XEP, MDP-1, and finally, MDP-2. Thus, by checking the ID marked by each receiving device after the relay packet transmission, the occurrence of an anomaly can be identified.
Mission network synchronization master
To smoothly perform data transmission by the relay system described above, it is necessary for the MDP and each instrument to perform synchronous processing and time division processing. To synchronize each instrument with the MDP, the TimeCode function is used. One second is divided into 16 slots, and, after the slot’s start time and slot number are delivered to each instrument by the TimeCode packet, the communication can be synchronized with all instruments. Such synchronization/time division processing has been carried out in various SpaceWire network systems and follows the method for guaranteeing the real-time property of SpaceWire (Yuasa et al. 2011; Raszhivin et al. 2013; Yamazaki et al. 2016; Clancy et al. 2016). Moreover, improvements were made to the mission data processing system: (1) multiple instruments can communicate with each other in each time slot and (2) the SpaceWire transmission function is improved in each time slot, and large wait times necessary to realize high-speed data transmission has been eliminated.
The time slot in this mission data processing system is 62.5 ms (1/16 s), and it is subdivided into the following periods.
-
1.
Fault detection, isolation and recovery (FDIR) period: 100 µs
The FDIR period is the period during which errors that occurred in the previous time slot are detected and restored. If there is an error in the relay packet transmission, as described in the above section “Relay packet in the mission network,” the transmission path is automatically switched to the redundant path. Therefore, when a faulty instrument has been detected in the mission network, it will be isolated by changing the path, and the transmission of the relay packet will resume using the new redundant path. Furthermore, the following checks are carried out. It is checked in this period that the relay packet has been received and other mission data packets have been sent within the same time slot. If the packet is continually sent over the time slot, the network checker will finish the RMAP communication by sending the early end of packet (EEP), defined by the RMAP regulation, to the sender to maintain the handshakes and timing in the mission network.
-
2.
Preparation period; 5 ms, including the FDIR period
The preparation period is the period of packet transmission/receipt collection that occurred in the previous time slot and preparation for packet transmission/reception that occurred in the current time slot.
-
3.
Communication period; 56.5 ms
The communication period is the period during which packets are sent and received.
-
4.
Idle period; 1 ms
The idle period occurs when the time margin is greater than ten times the jitter in the TimeCode distribution to each instrument.
As described above, by setting the FDIR period, it is impossible to transmit and receive packets across time slots. However, since the influence range of the communication is separated by the time slots, the influence range of anomaly in communications can be limited by the time slot. In addition, packet transmission/reception during the communication period involves hardware processing, and the wait time is kept to a minimum, while the necessary software processing is performed during the preparation period. Thus, it is possible to secure high speed and high reliability even in small-sized systems.
The distribution of spin index pulse
The observation instrument measures the direction of particle arrival and propagation of electromagnetic waves synchronously with the satellite spin. Therefore, the spin index pulse (pulses notifying the timing when the sun sensor has detected the sun in each spin) should be distributed to each instrument. The MDP receives the spin index pulse from the bus part as a pulse by an RS422 signal, a dedicated line. After the receipt, the MDP delivers the spin index pulses to each instrument using the TimeCode function with an error of 30 μs or less. The TimeCode used for the above synchronization of the time slot is distinguished by changing the identifier flag that is the empty bit of the time code in the RMAP regulation.
Mission data recorder (MDR)
In the WPI, the transfer rate for the observation mode, burst mode, maximum rate of mission, and data generated from multiple instruments is as high as 10.5 Mbps (Katoh et al. 2018; Hikishima et al. 2018). The generation time of the burst data is approximately 10–20 min per orbit (approximately 1–2 GB), but the WPI mode observation is carried out at each orbit (approximately 9 h/orbit); therefore, it is necessary to secure a large data storage area in the mission system because the downlink to the ground station transfers less than about 3 GB of data per day. We developed a new data recorder that has a few tens of GB in memory but is sufficient for the Arase mission data. A memory device having a data capacity of tens of GB is limited to the Flash-ROM when resources such as size and power are taken into consideration. Using a 40-GB Flash-ROM device (recording capacity is 32 GB), which is a three-dimensional high-density packaging module made by 3D-plus Co. Ltd., we have succeeded in developing an MDR that has a large stored memory but is as compact as an A5 sheet of paper. The 32-GB memory area is divided into approximately ten areas (partitions called “category”), and the data of different instruments are stored in each partition, available for use. As described below, since the necessary data is selected by the time retrieval module and processing is performed, it is necessary to write the data in different partitions for each set of data to be selected. Since it is necessary to write the Flash-ROM in block units, the MDR temporarily buffers input data of 10.5 Mbps on the synchronous dynamic random access memory (SDRAM). When the block size is reached or after a certain amount of time elapses, input data are written from the SDRAM to the Flash-ROM memory areas. In addition, to prolong the life of the Flash-ROM, which is limited by the number of times it can be written to, the Ware Leveling function is carried out. In Flash-ROMs, defective blocks are present as early as the manufacturing process, and new defective blocks are generated depending on the use frequency. Therefore, the Ware Leveling function detects a bad block, manages it through the use of a table, and performs controls preventing the writing of data to a newly generated bad block during operation. By writing input data from the top address to the end address of each partition area in the Flash-ROM memory, the number of write times on the device is made uniform and the life of the Flash-ROM is extended.
In previous scientific satellites, to acquire the data at the specified time from the data recorder, it was necessary to check the physical address corresponding to the time recorded in the housekeeping telemetry and set it as the command parameter of data acquisition. Meanwhile, the Earth observation satellite manages the data acquisition time by adding the time tag information (e.g., GPS time) to the data (Nakagawa 2010). By having similar functions, the MDR is specified to manage data with the time tag information.
The MDR-received data format conforms to the space packet (CCSDS) regulation as the upper layer protocol of the SpaceWire/RMAP (CCSDS 2012). When the MDR receives the data packet, it reads the application process identifier (APID) included in the space packet primary header and the category that is the MDR save destination area, and checks whether the corresponding area for the category exists. When there is a corresponding category, the received data is registered in a queue that is prepared for each category. The MDR creates the table that correlates the satellite time written in the received data with the physical address in which it is to be saved on the Flash-ROM, such that the time search function of the saved data in the MDR can be performed. The new “time search function” in the MDR was developed to facilitate access to the stored data. The time tag information is stored in the secondary header of the received space packet. This time the tag information is recorded in the data, not as the receipt time by the MDR, but as the time of data generation by each instrument.
Furthermore, we implemented a software application interface (API) that enables the retrieval of the stored data in the MDR using the time tag information. A user who has scientific expertize can perform all the functions that access the stored data, using the time information on both the satellite onboard program and the data downlink tool on the ground. With this interface, the user can more intuitively access the necessary observation data on natural phenomena of interest, to be reliably selected by the time information at which the phenomenon had occurred, avoiding choosing the wrong data in operations. By managing the time tag information of the data, a function to selectively delete data from time A to time B can be implemented. With this function, it is possible to selectively and safely delete recording data in the MDR that are low in scientific priority. Furthermore, the deleted area can be used as a storage area for new observation data, and therefore, the MDR can be used more efficiently.