Skip to content

Advertisement

Earth, Planets and Space
Earth, Planets and Space Cover Image
  • Full paper
  • Open Access

Design of a mission network system using SpaceWire for scientific payloads onboard the Arase spacecraft

Earth, Planets and Space201870:71

https://doi.org/10.1186/s40623-018-0839-z

©  The Author(s) 2018

  • Received: 7 September 2017
  • Accepted: 14 April 2018
  • Published:

Abstract

Arase is a small scientific satellite program conducted by the Institute of Space and Astronautical Science/Japan Aerospace Exploration Agency, which is dedicated to the detailed study of the radiation belts around Earth through in situ observations. In particular, the goal is to directly observe the interaction between plasma waves and particles, which cause the generation of high-energy electrons. To observe the waves and particles in detail, we must record large volumes of burst data with high transmission rates through onboard mission network systems. For this purpose, we developed a high-speed and highly reliable mission network based on SpaceWire, as well as a new and large memory data recorder equipped with a data search function based on observation time (the time index, TI, is the satellite time starting from when the spacecraft is powered on.) with respect to the orbital data generated in large quantities. By adopting a new transaction concept of a ring topology network with SpaceWire, we could secure a redundant mission network system without using large routers and having to suppress the increase in cable weight. We confirmed that their orbit performs as designed.
Graphical Abstract image

Keywords

  • The ERG project
  • Radiation belts
  • Geospace
  • SpaceWire
  • Mission data processor

Introduction

The Arase satellite was launched by the second Epsilon rocket on December 20, 2016, from the Uchinoura Space Center in Japan. Arase is dedicated to the detailed study of the radiation belts around Earth through in situ observations to determine when and how relativistic electrons are accelerated and disappear in the radiation belts during magnetic storms (Baker et al. 1986; Reeves et al. 1998; Rostoker et al. 1998; Miyoshi et al. 2012, in review). In particular, the goal is to directly observe the interaction between plasma waves and particles (wave–particle interaction: WPI), which is considered the cause of the generation of high-energy electrons. (Summers et al. 1998, 2007; Katoh et al. 2013; Hikishima et al. 2014) To observe waves and particles with an accuracy of a few 10 μs, we developed a new data recorder and processor that can store and process large amounts of data faster than previous models.

The Arase spacecraft was developed as the first selected project under the small scientific satellite programs of Institute of Space and Astronautical Science (ISAS)/Japan Aerospace Exploration Agency (JAXA) in 2012. As part of the program, the bus and mission modules of the spacecraft were developed separately. The bus module was developed as a common bus system for future small satellite missions; however, the mission module was optimized for each individual mission. The first bus module, known as the “SPRINT-bus,” was developed for the HISAKI project in ISAS/JAXA to shorten the development period and reduce the development cost (Nakaya et al. 2012). Arase used the SPRINT-bus system that was optimized for spin-stabilized spacecraft.

The Arase spacecraft consists of two modules, as shown in Fig. 1. The bottom module is the spacecraft bus system that controls the data handling, electrical power, thermal control, attitude control, propulsion control, and communication with ground stations. The top module is the mission module that includes eight scientific instruments, a Star Scanner (SSC), S-band antennas, and the mission network (Nakamura et al. 2017, in review). Arase is a spin-stabilized satellite, and the spin axis is oriented toward the sun. Therefore, all observation instruments acquire data synchronized with a spin. In Fig. 1, the spin axis is S-antenna3, which is placed at the center of the top panel of the mission module. The system block diagram of the Arase spacecraft is shown in Fig. 2. All components are interconnected by the SpaceWire network (bold lines in Fig. 2) (ECSS-E-ST-50-12C 2008). In the SPRINT-bus system, two large SpaceWire routers, “SWR-1” and “SWR-2,” shown in Fig. 2, form the center of the bus network and each component connects to the SpaceWire routers to communicate with telemetry and commands. The top-right side of the dashed square line in Fig. 2 shows the mission SpaceWire network. The instruments in the mission part are not connected directly to the router in the bus network (SWR1/SWR2) but are connected only to the mission data processor electrical box (MDP-E) by SpaceWire. The MDP-E is connected to the router in the bus network such that the failure in the mission section does not affect the bus system via the router. Furthermore, by connecting only the MDP-E to the bus, the interface between the mission and the bus network can be simplified, and the integration test with only the mission unit can be executed, independent of the development and testing of the bus. This is also suitable for small scientific satellites for which bus and mission modules are developed independently.
Fig. 1
Fig. 1

Cross-view of the Arase spacecraft. The lower part of the broken line slightly above the middle is the bus module and the upper is the mission module. Observation equipment is attached to the mission module section and acquires observation data. The Arase satellite is a spin-stabilized satellite, and the spin axis is consistent with the S-ANT 3 attached to the top panel of the mission module. The bus module is oriented in the direction of the sun and the mission module is designed to point in the opposite direction

Fig. 2
Fig. 2

The block diagram of Arase spacecraft bus and mission systems. The bus network has two different SpaceWire networks—one is the data communication, network connected to the SpaceWire router (SWR-1), and the other is the AOCS network, connected to the SWR-2. The mission network in the upper right side connects to the SWR-1 via MDP-E. Each instrument in the mission part is not connected to the bus network directly.

(This block diagram is taken from Figure 4 of Nakamura et al. 2017)

Mission module

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.
Fig. 3
Fig. 3

The diagram of mission power lines. Four power lines come from the bus power control unit independently. Two lines are connected to MDP-1/MDP-2 directly and the other lines are connected to three PDU (PSD#1–PSD#3). Power lines are distributed to each switch with a circuit breaker that controls the sensor for power on/off in PDUs

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.
  1. 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.

     
  2. 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).
Fig. 4
Fig. 4

The mission network of physical connections with SpaceWire. The blue line is the ring network connecting each instrument (CPU board) by SpaceWire. The sky-blue lines indicate paths from the ring network to MDPs. The green lines are SpaceWire interfaces between the bus (SWR-1) and the mission (MDP1 and MDP2) network

“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.
Fig. 5
Fig. 5

Diagram of the relay packet transmission in the mission ring network

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. 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.
  1. 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.
  1. 3.

    Communication period; 56.5 ms

     
The communication period is the period during which packets are sent and received.
  1. 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.

Performance on the orbit

Data are generated from eight instruments in the mission network, and the data transferred to the system data recorder in the bus network are controlled entirely within the transfer, band-limited by the MDP. In addition, the burst data are periodically written to the MDR in the same mission network. It has been processed continuously without problems since the end of March. Table 1 shows the design transfer rate and processing transfer rate in orbit. It is an execution band with approximately less than 10% of the design rate for normal data and approximately 60% of the design rate for burst data. The newly adopted SpaceWire-Ring mission network also works well within the margin of maximum performance.
Table 1

Design and processing transfer rate between March and July

Kind of packet

Design rate (D)

Processing rate (P)

Load of mission network (%)

Relay packet

655 kbps

655 kbps (fixed)

5.2

Normal data

540 kbps

Ave. 184 kbps

1.5

Max. 365 kbps

2.9

Burst data

11.3 Mbps

Ave. 115 kbps

0.9

Max. 7.52 Mbps

60.2

Total

12.5 Mbps

Ave. 954 kbps

7.6

Max. 7.66 Mbps

61.3

The Arase has orbited through radiation belts and concern has been raised about the effects of radiation on the equipment error. Since the MDP/MDR is a key component, the parts are manufactured using space grade MIL Class-V and Rad Hard/Rad Tolerant products. Table 2 compares the predicted rate of occurrence of radiation error and the error rate in orbit. SRAM, SDRAM, Flash-ROM, and the inner RAM of FPGA (RTAX2000) are used for the MDP/MDR, and since the resistance to radiation is different for each, an evaluation was performed for each memory type. The predicted value corresponds to when solar activity is “quiet” because present solar activity is very weak. The error occurrence frequency in orbit is almost the same as predicted. Considering that solar activity is quite low, we think that this is a reasonable result. In addition, 2-bit uncorrectable errors do not occur, and any 1-bit error is corrected by the error correction function. The single event latch-up (SEL) does not occur in orbit.
Table 2

1-bit in-orbit and predicted radiation error frequencies in the MDR

Kind of memory

SEL

SEU

Predict

Orbit

Predict

Orbit

Flash-ROM

Non

Non

1/3 min

1/43.4 min

SRAM

Non

Non

1/29.9 h

1/13.2 h

SDRAM

Non

Non

1/175 day

Non

RAM in FPGA

Non

Non

1/1.7 day

Non

Summary

We have successfully constructed a mission network in orbit, in which no errors or redundant system switching has occurred thus far, and showed that the network has performed as designed. In addition, we have developed a new large memory data recorder equipped with a data search function based on the observation time with respect to the orbital data generated in large quantities. Furthermore, we confirmed that its orbit performance is as designed. With the newly developed time search function, data selection and operation on the ground can be simplified, and efficient data acquisition has become possible.

Declarations

Authors’ contributions

TT contributed the design of the component and mission network system. EO, KA, and MH contributed discussion and specifications of mission network system. All authors read and approved the final manuscript.

Acknowledgements

The authors would like to express their sincere gratitude to all the members of the ERG project for their support and cooperations. The MDP/MDR components were manufactured by the Integrated Defense & Space Systems Mitsubishi Heavy Industries LTD, the middleware of the MDP/MDR were made by MHI Aerospace Systems Corp., and the real-time OS (T-Kernel 2.0 Aero Space) on the MDP/MDR was made by Ubiquitous Computing Technology Corp. and YRP Ubiquitous Networking Laboratory.

Competing interests

The authors declare that they have no competing interests.

Consent for publication

Not applicable.

Ethics approval and consent to participate

Not applicable.

Publisher’s Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Authors’ Affiliations

(1)
ISAS/JAXA, Sagamihara 252-5210, Japan
(2)
JAXA, Sagamihara 252-5210, Japan

References

  1. Baker DN, Blake JB, Klebesadel RW, Higbie PR (1986) Highly relativistic electrons in the Earth’s outer magnetosphere, 1. Lifetimes and temporal history 1979–1984. J Geophys Res 91(A4):4265–4276View ArticleGoogle Scholar
  2. CCSDS Secretariat Office of Space Communication (Code M-3) National Aeronautics and Space Administration, “SPACE PACKET PROTOCOL” CCSDS 133.0-B-1 Cor. 2, September 2012Google Scholar
  3. Clancy SC, Shihabi MM, Angkasa KS (2016) Using SpaceWire time codes for spacecraft time synchronization. In: International SpaceWire conference, JapanGoogle Scholar
  4. ECSS-E-ST-50-12C (2008) (SpaceWire), SpaceWire-links, nodes, routers and networks. European Cooperation for Space StandardizationGoogle Scholar
  5. ECSS-E-ST-50-52C (2010) (RMAP), SpaceWire—remote memory access protocol. European Cooperation for Space StandardizationGoogle Scholar
  6. Hikishima M, Katoh Y, Kojima H (2014) Evaluation of waveform data processing in wave–particle interaction analyzer. Earth Planets Space 66:63. https://doi.org/10.1186/1880-5981-66-63 View ArticleGoogle Scholar
  7. Hikishima M et al (2018) Data processing in the software-type wave-particle interaction analyzer on the Arase Satellite. Earth Planets Space. https://doi.org/10.1186/s40623-018-0856-y Google Scholar
  8. Katoh Y, Kitahara M, Kojima H, Omura Y, Kasahara S, Hirahara M, Miyoshi Y, Seki K, Asamura K, Takashima T, Ono T (2013) Significance of wave–particle interaction analyzer for direct measurements of nonlinear wave–particle interactions. Ann Geophys 31:503–512. https://doi.org/10.5194/angeo-31-503-2013 View ArticleGoogle Scholar
  9. Katoh Y et al (2018) Software-type wave–particle interaction analyzer on board the Arase satellite. Earth Planets Space 70:4. https://doi.org/10.1186/s40623-017-0771-7 View ArticleGoogle Scholar
  10. Miyoshi Y, Ono T, Takashima T, Asamura K, Hirahara M, Kasaba Y, Matsuoka A, Kojima H, Shiokawa K, Seki K, Fujimoto M, Nagatsuma T, Cheng CZ, Kazama Y, Kasahara S, Mitani T, Matsumoto H, Higashio N, Kumamoto A, Yagitani S, Kasahara Y, Ishisaka K, Blomberg L, Fujimoto A, Katoh Y, Ebihara Y, Omura Y, Nose M, Hori T, Miyashita Y, Tanaka Y, Segawa T, ERG Working Group (2012) The Energization and Radiation in Geospace (ERG) project. In: Summers D, Mann IR, Baker DN, Schulz M (eds) Dynamics of the earth’s radiation belts and inner magnetosphere, geophysical monograph series, vol 199. AGU, Washington, pp 103–116. https://doi.org/10.1029/2012bk001304 Google Scholar
  11. Nakagawa K (2010) GCOM-W and GCOM-C project status. In: Proceedings of IGARSS 2010, pp 1355–1358Google Scholar
  12. Nakamura Y et al (2017) Exploration of energization and radiation in geospace (ERG): development, preliminary flight results, and lessons learned in JAXA’s small satellite project. In: 31st annual AIAA/USU conference on small satellitesGoogle Scholar
  13. Nakaya K, Fukuda S, Sakai S, Yamazaki A, Uemizu K, Toriumi T, Takahashi J, Maehara M, Okahashi T, Sawai S (2012) Development of flexible standard bus for ISAS/JAXA small scientific satellite series. Trans Jpn Soc Aeronaut Space Sci Aerosp Technol Jpn 10(28):5–9Google Scholar
  14. Raszhivin D, Sheynin Y, Abramov A (2013) Deterministic scheduling of SpaceWire data streams. In: International SpaceWire conference, SwedenGoogle Scholar
  15. Reeves GD et al (1998) The relativistic electron response at geosynchronous orbit during the January 1997 magnetic storm. J Geophys Res 103(A8):17559–17570View ArticleGoogle Scholar
  16. Rostoker G, Skone S, Baker DN (1998) On the origin of relativistic electrons in the magnetosphere associated with some geomagnetic storms. Geophys Res Lett 25(19):3701–3704View ArticleGoogle Scholar
  17. Summers D, Thorne RM, Xiao F (1998) Relativistic theory of wave–particle resonant diffusion with application to electron acceleration in the magnetosphere. J Geophys Res 103(A9):20487–20500View ArticleGoogle Scholar
  18. Summers D, Ni B, Meredith NP (2007) Timescales for radiation belt electron acceleration and loss due to resonant wave–particle interactions: 1. Theory J Geophys Res 112:A04206Google Scholar
  19. Yamazaki S, Tonouchi T, Otake Y, Sota Y, Tanaka T, Hihara H (2016) Constraint-based configuration table generator for reliable path routing and safe timeslot allocation in SpaceWire network. In: International SpaceWire conference, JapanGoogle Scholar
  20. Yuasa T, Takahashi T, Ozaki M, Kokubun M (2011) A deterministic SpaceWire network onboard the ASTRO-H space x-ray observatory. In: International SpaceWire conference, USAGoogle Scholar

Copyright

© The Author(s) 2018

Advertisement