Mission Overview for the Radiation Belt Storm Probes Mission
Provided here is an overview of Radiation Belt Storm Probes (RBSP) mission design. The driving mission and science requirements are presented, and the unique engineering challenges of operating in Earth’s radiation belts are discussed in detail. The implementation of both the space and ground segments are presented, including a discussion of the challenges inherent with operating multiple observatories concurrently and working with a distributed network of science operation centers. An overview of the launch vehicle and the overall mission design will be presented, and the plan for space weather data broadcast will be introduced.
KeywordsNASA Space weather Radiation belt Magnetosphere Geomagnetic storm
2 Mission Requirements
The science goals drive certain key requirements that define the rest of the mission system. Here we describe selected requirements for the RBSP mission, with an emphasis on those requirements that had the greatest impacts on the mission design (the driving requirements).
2.1 Orbit Definition & Mission Life
The science goals drive certain key requirements that define the rest of the mission system. The most fundamental of these requirements is that the mission fly two functionally equivalent observatories in orbits that take them through the various regions of the Earth’s radiation belts. Specifically, the orbits are required to have an apogee altitude between 30,050 km and 31,250 km, a perigee altitude between 500 km and 675 km, and an orbital inclination of 10∘±0.25∘. These constraints place the observatories in orbits that cut through both the inner and outer radiation belts, and which sweep through all local Solar times as the orbit precesses over time.
2.2 Operate—Through “Storm” Events
As this is a mission to study radiation belt science, the observatories must continue to operate in the harsh radiation environment. One key goal of the investigation is to observe the effects and the processes at work during a Solar storm, so the observatories must continue to collect science data through the worst expected storm environment. This requirement, particularly on a mission that is categorized as Risk Category C and thus contains only limited hardware redundancy, significantly drove the design of the flight system. The impacts this requirement imposes on the design of the system are discussed in greater detail below.
2.3 Electromagnetic Cleanliness and Control
The RBSP science investigation relies on an accurate understanding of the ambient environment in which the various measurements are being made. This drives the need for both magnetic and electric (differential charging) cleanliness of the observatories. Each observatory is required to have a residual magnetic field (as measured at the magnetometer locations) of less than 5 nT, with dynamic variations of this residual field of less than 0.1 nT. Similarly, the observatory-generated electric field as measured at the tip of the EFW axial booms is required to be less than 4 mV/m, even in the worst-case charging environments. Again, the effect of these requirements on the design of the flight system is discussed in more detail below.
2.4 Inter-instrument Requirements
The use of a suite of multiple instruments to capture the various data products required for the investigation dictates the need for significant coordination between these instruments and with the spacecraft bus itself. The ability to correlate the relative time of measurements from different instruments is required to allow the science team to distinguish temporal behavior within the radiation belts, and this in turn drives the need for accurate time knowledge between the instruments and also with the spacecraft avionics. The value of the science gathered can also be significantly enhanced if the instruments have the ability to share some amount of data in real-time. For example, an instrument can send out a “flag” that a significant even is occurring, and other instruments can then trigger off this signal and increase capture data rates or switch instrument modes to better investigate the event. This provides the best possible chance of capturing the high-value data associated with storm events.
2.5 Attitude Determination & Control
As with most spacecraft, attitude knowledge plays an important role for this mission. The science investigation requires a post-processed attitude knowledge of ≤3 degrees (3-sigma). Both observatories are nominally Sun-pointing and spin stabilized. To maintain the observatory’s Sun sensors within the operational range and to ensure sufficient power system margins, the total off-pointing angle between each observatory and the Sun-Earth line is required to remain within the range of 15–27 degrees. Further, each observatory is required to operate within the spin range of 4–6 RPM during normal operations, and to maintain the spin rate within 0.25 RPM once the nominal spin rate is established.
3 Mission Design
The nominal injection orbits of the two observatories are approximately 600 km × 30,500 km, which results in an orbit period of approximately 9 hours and 3 minutes, and as stated previously the orbit is at a 10∘ inclination. The difference in apogee between RBSP-A and RBSP-B causes RBSP-A to continually “lap” RBSP-B, with a lapping rate of approximately four times per year. That is, over a period of 90 days, RBSP-A evolves 239 orbits while RBSP-B evolves 238 orbits. Thus, throughout the mission the two observatories are constantly changing their relative positions, allowing the mission science team ample opportunity to study both the temporal and spatial effects of changes in the radiation belts.
The current manifested launch date for the RBSP observatories is 23 August 2012, though the mission design allows for a launch opportunity on any day of the year. The launch injection point is chosen such that the apogee of each observatory orbit, expressed in Local Solar Time (LST), will pass through local Solar dawn approximately 71 days after launch. This allows the observatories to proceed through their 60-day commissioning period with some margin before the required start of nominal science operations. The apogee LSTs then precess through all local Solar times between dawn and dusk over the course of the first year of nominal science operations, and the apogee LSTs will pass through all local Solar times in the two year nominal mission.
Because of varying declinations of the Sun throughout the year, the rate at which apogee LSTs precess from their initial launch value to local Solar dawn also varies; that is, the precession rate is dependent on launch date. To hold the 71-day precession requirement, the varying precession rates require the design of multiple launch trajectories that have various initial apogee LSTs relative to local Solar dawn. This in turn requires a varying daily launch time throughout the year.
Because of acceptable granularity in the desired initial LSTs, it is possible to group several adjacent launch days to have the same targeted LST. The 366 day year was condensed into 32 unique daily LSTs, and then reverse propagated to find their associated launch times. The earliest launch time was found to be 08:05 UTC for 29–31 August and 6–9 September, while the latest launch time was found to be 08:54 UTC for 28–29 April and 8 May.
This mission design results in an orbit with a period of approximately nine hours, and the low inclination means that most orbits include periods of eclipse. The maximum eclipse time the observatories will see is approximately 114 minutes when the orbit apogee LST is passing through local midnight, though most eclipses are of significantly shorter duration. This in turn drives the design of both the power generation and thermal management systems. This orbit design also provides for multiple ground contact opportunities for each observatory on most days, and at least one ground contact opportunity for each observatory on each day.
4 Launch Vehicle Overview and Interfaces
The Atlas V 401 launch vehicle is a two-stage rocket that does not have any solid rocket motors. Approximately 4 minutes after liftoff the Centaur second stage of the launch vehicle separates from the first stage and begins the first of two long burns. Fairing jettison occurs 8 seconds after the start of the first second stage burn, and the burn lasts for just under 10 minutes. The vehicle then enters a coast phase of approximately 55 minutes to achieve the desired geometry prior to final injection. After performing an approximately 5 minute second burn of the second stage, the launch vehicle turns to a near-Sun pointing attitude, spins up to 5 RPM and releases RBSP A approximately 79 minutes after liftoff. The launch vehicle then performs a short maneuver to raise the apogee of RBSP B, orients to the desired separation attitude, spins to 5 RPM and then separates the second observatory approximately 91 minutes after launch. Finally, the Centaur second stage performs a controlled de-orbit maneuver and reenters the atmosphere over the southern Atlantic Ocean approximately 12 hours after liftoff.
5 Instrument Payload & Data Management
Baseline particle measurement requirements
Number of platforms
High energy electrons
1 distribution per minute
30 % at 3 MeV
Medium energy electrons
1 distribution per minute
30 % at 0.3 MeV
High energy protons
1 distribution per minute
40 % at 30 MeV
Medium energy protons
1 distribution per minute
40 % at 0.3 MeV
Medium-energy ion composition
1 distribution per minute
40 % at 0.05 MeV
Low-energy ion/electron composition
1 distribution per minute
20 eV–0.05 MeV
40 % at 0.01 MeV
Baseline fields and waves requirements
Number of platforms
3-D magnetic field
3-D wave magnetic field
10 Hz–10 kHz
20 channels per decade
3-D wave electric field
10 Hz–10 kHz
20 channels per decade
3-D electric field
Average daily data rate and volume
Daily average data rate (kbps)
Average daily data volume (Gb)
EMFISIS waves survey
EMFISIS mag survey
EMFISIS burst (downlink allocation)
5.1 Electric and Magnetic Field Instrument Suite and Integrated Science (EMFISIS)
5.2 Electric Field and Waves (EFW) Instrument
5.3 Radiation Belt Storm Probes Ion Composition Experiment (RBSPICE)
5.4 Energetic Particle, Composition and Thermal Plasma Suite (ECT)
5.5 Proton Spectrometer Belt Research (PSBR)
5.6 Data Management
The mission science requirements dictate that an average of 5.9 Gb of science data be returned from each observatory per day during normal science operations. The nominal operations plan calls for daily contacts with the observatory to allow this data volume to be downlinked every day, but the observatory solid state recorders are sized to allow the observatory to miss a day of contacts without losing any science data. Each instrument has the ability to set its own data recording rate, but data storage is managed by the spacecraft flight software and this software will begin to overwrite science data (starting with the oldest data from that instrument suite) should a given suite overrun its onboard storage allocation. An indication of the percentage of a given instrument suite’s current data usage is downlinked via standard housekeeping telemetry and provided to each Science Operations Center. The responsibility for managing science data storage within allocations therefore falls on each of the instrument operations teams. The average daily data rates and resulting average daily data volume for each instrument suite is presented below in Table 3. Note that the total daily data volume includes instrument and spacecraft housekeeping data, and is therefore greater than the 5.9 Gb of required daily science data.
6 Spacecraft Overview
Power generation and storage is achieved respectively via four solar arrays and an eight cell 50 AHr Lithium-ion battery. In addition to these, the Power Generation System (PGS) includes the Power Switching Electronics (PSE), which limits the maximum bus current, limits the battery voltage and provides the telemetry and command interfaces to operate and monitor the PGS components. The Power Distribution Unit (PDU) provides power switching functionality, and contains circuit breakers and fuses for all non-critical loads.
The RF communications system contains a single transceiver, an 8 Watt solid-state power amplifier (SSPA), a diplexer, and two broadbeam, near-hemispherical antennas. The system provides S-band uplink, downlink and radiometric tracking capability. It supports both 1/2 turbo and convolutional encoding, and it uses coherent downlink to allow for Doppler navigation. The system provides a downlink rate of 1 kbps to 2 Mbps, and an uplink rate of 125 bps (emergency rate) to 2 kbps.
Attitude determination is accomplished by two means. The Flux-Gate Magnetometer sensor is the primary sensor for determining definitive observatory attitude. The data from this sensor is not processed on-board, so additional sensing is required to allow for autonomous attitude sense for observatory health and safety. The on-board attitude determination is accomplished via two Sun sensors. These sensors provide coarse observatory attitude information that is sufficient for autonomous monitoring of health and safety. This data is also sent to the ground where it is used in the estimation of definitive observatory attitude used for science processing. Each observatory also includes two passive nutation dampers that help maintain a stable system attitude and damp out any “wobble” after propulsive maneuvers.
The propulsion system is a simple monopropellant blowdown system. Three Inconel tanks store the 56 kg of hydrazine propellant onboard, and feed the eight 0.9 N thrusters. The position and orientation of these eight thrusters allow for spin up and spin down about the primary spin axis, positive and negative precession about the spin-plane axes, and velocity change toward and away from the sun. These thrusters are the only active attitude control mechanisms on board the observatories, and provide the full set of capability required to maintain the system attitude and spin rate and perform orbit corrections, collision avoidance maneuvers as required, and the final de-orbit burn at the end of the mission.
The spacecraft structure consists of a primary load-bearing central cylinder and aluminum honeycomb decks with aluminum facesheets for mounting instruments and spacecraft components. The two Observatories are held together by a RUAG-supplied Lightband low-shock separation system. This same separation system is also used between the stacked Observatories and the launch vehicle.
The spacecraft also includes diagnostic instrumentation—termed the Engineering Radiation Monitor (ERM)—to monitor the in-situ radiation environment. The long-term health and operability of observatory electronics and materials are directly affected by the total incident radiation dose. The ERM will measure this incident dose, and will provide a means for correlating upsets in observatory electronics with the environment present at that time. This monitor will also allow refinement of the standard total dose curves that are traditionally used for the design of spacecraft that operate in the Earth’s radiation belts.
6.1 Fault Protection
Each observatory also includes robust Fault Protection and Autonomy systems that work together to maintain the overall health and safety of the flight segment. Because the observatories includes limited hardware redundancy, the Fault Protection and Autonomy systems are of particular importance on RBSP. The architecture uses a layered response approach to maximize science data collection in the event of a fault. The system protects against the extended loss of communications by way of both software and hardware command loss timers. It also monitors the Sun angle of a given observatory, and can safe the system and notify the ground in case of an exceedance of the minimum or maximum sun angle. Similarly, the Fault Protection system monitors the bus voltage and battery state of charge, and can safe the system in case of a Low Voltage Sense (LVS) or a Low Battery State of Charge (LBSOC) where the bus voltage or battery state of charge drop below a minimum preset level.
The system also monitors the current condition and the health of observatory components, and it has the ability to individually off-pulse the primary unswitched loads (the IEM, the PDU and the transceiver) to restore those systems to a known startup configuration and presumably to clear any faults that my be present. In addition to monitoring and managing spacecraft bus health and safety, the system can also monitor instrument currents and heartbeats and can power off instruments in the case of a fault, and they can also individually power off the instruments based on a turn off request generated by that instrument.
Lastly, the fault protection system manages the separation sequence after launch, deploying the solar arrays and powering on the RF downlink (uplink is enabled by default at launch).
7 Mission Operations
7.1 Mission Operations Overview
The mission operations concept is designed for mostly unattended observatory operations, with distributed science operations. Because the observatories are spin-stabilized and nominally sun-pointing, they are inherently in a safe state and the need for constant monitoring is minimized. All critical activities—including commissioning activities and all propulsive maneuvers—are performed in contact with the ground. Nominal science operations are not constrained to occur during “staffed” periods of time. Similarly, the instrument operations are performed “offline” of the MOC, and instrument commands are queued up at the MOC remotely from the SOCs, then uploaded to the observatory during the next regular contact. This approach of unattended, decoupled operations greatly reduces the cost of the operational phase of the mission, and it has been successfully demonstrated at APL on the STEREO mission.
Operational data rates vary for each instrument suite with the nominal rates ranging between 2 and 33 Kbps. The system also accommodates a “burst” data collection mode from the EMFISIS instrument suite of just over 1 Mbps. Each observatory is required to downlink an average of at least 5.9 Gb of science data per day during the nominal science mission.
The observatory’s stable, sun-relative attitude drifts with the motion of the Earth, but the attitude of the observatories is set such that an East-West precession maneuver to maintain Sun on the arrays is only required about once every three weeks. Similarly, a North-South precession maneuver is required once per year to adjust for seasonal drift relative to the ecliptic plane. Apart from any initial orbit injection correction and the end-of-mission deorbit maneuver, these are the only propulsive maneuvers required during the mission.
As mentioned above, the observatory system does include two Sun sensors for onboard attitude determination to support observatory health and safety, but the primary method of attitude determination is performed during post-processing on the ground. The measurement of the local magnetic field from the Flux Gate Magnetometer (Mag) is transmitted from the observatory to the ground system as part of the normal science data downlink during each ground pass. This data is then processed by the Guidance & Control (G&C) system’s ground software and compared to the reference standard model for the Earth’s magnetic field. The accuracy of this model, and the general stability of the Earth’s magnetic field, allow this method to provide an accurate prediction of the observatory attitude. A “quick-look” version of this attitude estimation is provided within 24 hours of receipt of data, and the estimate is further refined after calibration and post-processing of the magnetometer data by the science team. This final attitude estimate is provided within one week of receipt of the data, and is used for final processing of all science data.
Per NASA requirements, the mission is obligated to dispose of both observatories at the end of the mission lifetime. Although the observatories carry sufficient propellant to do so, they have insufficient thrust levels to perform a controlled reentry burn that would deposit the observatories reliably in a targeted broad ocean area. As-designed approximately 1/3 of the mission propellant budget is designated to disposal of the observatories. The deorbit plan calls for performing a maneuver to lower the perigee of the observatories, and then rotating each spacecraft to have the solar arrays nearly edge-on to the Sun such that as the observatory continues to naturally precess the arrays will point away from the sun and the battery will slowly drain over time. At the completion of this precession maneuver, the team will perform a net-zero propulsive maneuver to drain the propellant reserves from the tanks, thus eliminating any stored energy onboard the observatory. This leaves the spacecraft in a safe, passivated state where they remain as the orbit naturally decays. Approximately six months after these decommissioning activities occur the atmospheric drag takes over and the observatories reenter Earth’s atmosphere.
7.1.1 Ground Segment
7.1.2 Mission Operations Center
7.1.3 Features of the MOC Facility
The Ground System Hardware architecture used on the RBSP Mission is client/server based. The PC-based computers acting as clients are running the Linux operating system. Servers are housed in the network room separate from the MOC.
The Ground System software includes L-3’s InControl, the primary command and control system for RBSP, and contains interfaces with the planning and assessment software and real-time tools developed by APL.
7.1.4 Science Operations Centers (SOC)
The Science Operations Centers (SOCs) are owned and operated by the Instrument teams to control the Instrument Operations. Each of the Instrument Suites has both a Test SOC and a Flight SOC. The Test SOCs are located at APL in a room adjacent to the MOC. This facility is used during some of the pre-launch testing and during the Commissioning Phase. During the Commissioning Phase it is desired to have the Instrument Teams in close proximity to the Mission Operations Team because of the possibility of a dynamic timeline of activities required to occur throughout the Commissioning Phase. During that time is it highly desirable to be able to have face to face communications as much as possible to reduce the risk of possible miscommunications amongst the various teams. The Flight SOCs reside at a facility of the Instrument Team’s choice. In many cases, they have chosen their home organizations. The details of the Instrument Operations and Instrument SOCs are provided in the instrument investigation papers within this special issue.
7.1.5 MOC Data Server
The MOC Data Server is the “hub” of data product transfer and resides in the MOC area. The various data products produced for the day to day operations are placed on the MOC Data Server for access by the various teams, especially the SOC Teams. In addition, the Level 0 Telemetry files are place there after their processing is complete.
7.1.6 Ground Stations
7.1.7 Navigation Function
The Navigation function for RBSP is produced by a team at APL. Doppler data is received from contacts with the various ground station antennas and that is used to produce the definitive orbit on the ground. The Navigation team will also produce predicted orbit products that are used in the Mission Operations Planning function.
7.1.8 Guidance and Control on the Ground
The Guidance & Control (G&C) function on the ground is used to produce predicted and definitive attitude solutions for use in the Planning functions as well as data processing. In the G&C Component within the MOC, the attitude data products are based on the sun sensor data and the Magnetometer data transmitted from the RBSP observatories.
7.2 Mission Operations Functionality
The Mission Operations System (MOS) includes the team, hardware, software, and facilities involved in operating the RBSP observatories on a daily basis. The primary tasks are to maintain healthy spacecraft and obtain the science data placed on the Solid State Recorder (SSR) by the Science Instruments. Mission Operations functionality is broken down into the Planning and Scheduling, the Real-time Control, and the Performance Assessment functions. Each of these functions feed into the other in order to conduct a safe and efficient mission.
7.2.1 Mission Operations Team
At the heart of the Mission Operations System is the Mission Operations Team. The team is comprised of Mission Operations Analysts and Flight Controllers. The Mission Operations Analysts are lead engineers who conduct all of the functions within Mission Operations, while Flight Controllers are less experienced and focus on the Real-time Control aspect. During the Launch and Commissioning Phase of the mission, the team is sized in order to be able to perform 24/7 operations; which may be required in order to conduct all of the required activities during the 60 day period. Once into the nominal science operations Phase of the mission, the majority of contacts will be run in an “Unattended” sense. This eliminates the need for Flight Controllers and the team remains staffed with the Analysts. The team is still required to staff contacts during which critical activities are performed. The majority of those activities are the propulsive maneuvers. The team of Mission Operations Analysts will rotate through positions on the Mission Operations team and will switch between operating RBSP A and B as part of the rotation.
7.2.2 Mission Operations Concept
The RBSP Mission Operations Concept is based on the Decoupled Operations approach. The Decoupled approach is enabled by the mission itself and the spacecraft design. The relative observatory attitude remains constant and the power system is sized to allow 100 % duty cycle of the instruments. The decoupled operations concept is implemented by distributing the Science Instrument Operations amongst the teams that developed those Instruments. While the Mission Operations Team operates the spacecraft bus, the teams within the Science Operations Centers (SOC) operate their individual instruments independent of the bus operations and the operation of the other Instruments. The SOCs send instrument commands into the MOC where they are stored in command queues until a ground station contact, when the queues are opened and the commands are transmitted to the Instrument on-board the observatory. The SOCs may receive housekeeping telemetry during the contacts by connecting to the MOC and will receive the Science data after contacts by retrieving the Level 0 telemetry files from the MOC Data Server (MDS). Additionally, the MDS will store many data products the various teams will need to conduct routine operations. The Mission Operations management of the SSR is simplified on RBSP because of the on-board file system and the use of CCSDS File Delivery Protocol (CFDP). Using the closed loop CFDP functionality, the ground system and observatory will communicate autonomously to ensure the data has been received on the ground prior to the data being deleted on-board. While closed loop CFDP will be employed when in contact with the APL Ground Station, during contacts with a USN station, an open loop version of CFDP will be employed due to the lack of the ability of exchanging the CFDP communications in real-time. Initially, the SSR will be configured in a simple “dump and delete” mode during USN operations; however, if an alternate solution would benefit, that concept may be adjusted after some experience is gained.
7.2.3 Mission Operations Planning Function
The RBSP Planning function is used for scheduling observatory activities necessary for safe and efficient operations. These activities include RF Control for Ground Station Contact, SSR Control, Eclipse entry and exit notifications, various Housekeeping functions, and Maneuvers. The activities, also known as Events, are comprised of repeatable command sequences which may have various instantiations depending on the specific scheduling criteria. All Events are classified as either routine or sporadic. Routine events are scheduled on regular intervals, whether it is based on time or per contact. A web-based tool known as “Scheduler” is a ground software tool used by the Mission Operations Team for developing the weekly schedule of events. The Scheduler tool schedules routine events automatically based on their pre-defined scheduling criteria. Sporadic events are placed in the schedule by the Mission Operations Team at the appropriate time. Due to gradual observatory precession throughout the orbit, the Mission Operations Team is required to schedule an Attitude adjustment maneuver every 21 days to keep the spin-axis within specifications. While this is a routine event, it also is classified as a Critical Event and therefore must be scheduled during a ground station or TDRSS contact that will be staffed. For this reason, these maneuvers are scheduled more on a manual basis every three weeks.
The Planning function is begun three weeks out in the Contact Scheduling process. Each successive week, the timeline of activities that occur on the contacts are firmed up to the point where commands are generated the week prior to planned execution. The primary tool used in the planning process is the Scheduler tool. Scheduler itself is an APL-developed web-based platform independent tool that makes use of user-generated templates mapped to each event type. Each template is designed to make use of a repeatable command sequence that allows arguments to be input for definition of specific instances each time it is scheduled. Based on its architecture, the “Scheduler” tool allows the Mission Operations Team to conduct planning or view all related planning information from their office, the MOC, or a remote location.
Also in the Planning process, Simulators are used to verify proper command sequencing for particular observatory activities. There are two types of Simulators employed by the RBSP Mission Operations Team. One type is hardware based (RBSP Operations Simulator, or RBOPS) and the other is software based (Flight Accelerated Simulation Tool, or FAST).
There are three hardware-in-the-loop simulators of various fidelities. The high fidelity RBOPS includes versions of the spacecraft IEM, PDU, and Transceiver. The other less fidelity RBOPSes have only a spacecraft IEM. Surrounding the RBOPS Simulators is a Testbed which is used to emulate the remaining virtual spacecraft components. The Software Simulator is used as the primary method of constraint checking of spacecraft command sequences prior to uplink.
The final part of the Planning process involves the final creation of Contact Plans and associated procedures and scripts. These are transferred to the MOC for execution during the Contact.
7.2.4 Real-time Contact Operations
The Real-time Control Function is the aspect of Mission Operations where communications occur between the ground and observatories during the Ground Station Contacts. During the Launch and Commissioning phase, the contacts taken will be staffed by members of the Mission Operations Team, Engineering Team, and Instrument Team members. This is because the majority of commissioning activities will be conducted in real-time during a contact. Once the mission enters the Routine Science Phase, the majority of contacts will be taken on an unattended basis. Unattended contact operations are planned for all contacts except for those during which critical activities will take place. During the Routine Science Phase, the instruments are powered and constantly sending data to the SSR. The majority of observatory activities are not critical and can be scheduled during unattended contacts. The only critical activities in this phase are maneuvers and possible anomaly recovery activities. Those will be scheduled during staffed contacts. During all contacts, including unattended, the spacecraft housekeeping telemetry is evaluated for state of health and the ground system is setup to provide remote notification of specific alarms to the Mission Operations Team for spacecraft alarms and to the Instrument/SOC teams for specific instrument alarms. Following the initial state-of-health evaluation, the SSR downlink is initiated. Spacecraft commanding is then performed, followed by the opening of the different SOC Command Queues, so that Instrument commands that had been waiting will be uplinked. Following notification of an alarm, the remote Mission Operations Team members may log in and begin evaluation of the urgency of the situation. If urgent, they can remotely schedule additional contact time and alert other members of the team to begin troubleshooting the anomaly. If the situation is not urgent, the team members choose a course of action less pressing that maintains the health and safety of the observatories and science objectives.
In order to downlink the amount of science data acquired on the SSR on a daily basis, the Mission Operations Team will schedule approximately three hours of contact time per day per observatory. In order to obtain this much contact time as well as to obtain the contact time for maneuvers and other necessary activities to be done outside of SSR downlinks, the project will utilize three different networks. The primary antenna is the APL 18 m (60 foot) antenna.
With the 18 m, the MOC will communicate with the Satellite Control Facility (SCF) to initiate observatory commands and receive telemetry. If necessary for a data rate change during a contact, the MOC initiates scripted commands to configure both the observatories and the ground station properly for a given change. Also, during the contacts with the APL station, the closed loop CFDP communications will occur.
To supplement the ability to obtain all of the Science data on the SSR, in particularly during times of year when communication opportunities with the primary station are minimal, two stations from the Universal Space Network will be used—those in South Point, Hawaii and in Dongara, Australia. The data throughput from the USN stations to the MOC is insufficient for real-time communication, therefore, the SSR data return path to APL from the USN stations is a store and forward method after the contact. This also prohibits the use of the closed loop CFDP. During data rate changes necessary for USN contacts, a communication will be made ahead of time for the Ground Station to make the change at the coordinated time.
Use of the TDRSS Space Network (SN) will take place during times where contact is required and ground station visibility and/or availability is not possible. This occurs mostly during periods of time during the Launch and Commissioning phase and during maneuvers and possible times of contingency operations during the Routine Science Phase. During TDRSS contact the downlink rate for RBSP is limited to 1 kpbs and therefore SSR downlink is not scheduled.
7.2.5 Performance Assessment
The Performance Assessment function is broken down into two classifications. One type is Routine Assessment which involves alarm processing and trending. The other type is anomaly investigation and resolution. Routine Assessment consists of determining the status, configuration, and performance of each spacecraft Subsystem. Alarm processing is performed on all observatory housekeeping data that is collected via the SSR as well as real-time. The Alarm processing software notifies the MOT of an unusual occurrence or condition of the observatory. Each alarm is evaluated by the team to determine a proper course of action to understand the cause and if necessary, remedy the alarm condition. Trending is the periodic monitoring of critical bus components, including those components that are known to degrade over time. Trend Analysis software automatically generates plots that are produced on routine intervals—on a daily, weekly, monthly, quarterly, and annual basis. Various data averaging is used for each time interval. The Mission Operations Team reviews the plots on a daily basis to monitor for any usual occurrences or possible trends.
The other function within Performance Assessment is the investigation and resolution of anomalous behavior identified either during real-time contact or during off-line assessment of performance. Anomaly Reports are written when an anomalous condition is first identified. The Performance Assessment function within Mission Operations further investigates to understand the cause and to determine a path of resolution. In some cases, the resolution may involve changes to processes, procedures, command sequences, and possibly alarms. These changes are documented as part of the anomaly closeout process.
The Performance Assessment function closes the loop within the Mission Operations Process by feeding changes necessary because of issues uncovered during the Real-time or Assessment aspects, onto the Planning function, to continue to try to improve Operations efficiency.
8 Space Weather
During normal science operations, the observatories will only require approximately 2.5 hours of ground contact time per day to downlink the stored science and housekeeping data. When the observatories aren’t in primary ground contacts they will be broadcasting space weather data intended to be received by participating ground stations throughout the world. This space weather data is a subset of the full science data normally being collected by the instruments, and all of the RBSP instruments contribute to the space weather data products. The data subset will include particle fluxes at a variety of energies as well as electric and magnetic fields. The science operations teams also have a goal of providing “quick look” data products that will fill in the gaps of space weather data that occur when the observatories are in primary ground contact, thus providing essentially continuous 24 hour coverage of space weather data. The space weather broadcast is performed using the observatory’s primary S-band RF communications system.
9 Unique Challenges for RBSP
The demanding science requirements and the routine operation of the observatories in the radiation belts create some unique design challenges for the RBSP mission.
The most obvious effect of operating in the radiation belts is, of course, the constant bombardment by damaging high-energy electrons and ions. This can lead to the well-known effect of displacement and ionizing damage in electronic parts, but it also causes two other effects that must be mitigated to ensure observatory health and mission success. Internal Charging and Deep Dielectric Discharge are both caused by high-energy electrons and ions penetrating the observatory structure and coming to rest in the spacecraft. These particles ultimately cause internal surfaces to charge until they exceed the breakdown or gap voltage, at which point it discharges to the local ground. This discharge can result in damage to electronic circuits, or can cause upsets or noise in spacecraft subsystems or instruments.
The launch vehicle selected for this mission has a great deal of lift capability to the RBSP orbit, and as such the project was in the enviable position of being able to use mass to solve some technical problems early in the design phase. This allowed the project to dictate that all observatory electronics (including on the instruments) be shielded by an equivalent of 350 mils of aluminum, thus effectively eliminating the internal charging and DDD effects within electronics boxes. Filtering circuits were also added to the inputs of each box to mitigate the effects of discharge-induced noise on signal lines.
A challenge related to this is the need for RBSP to operate through significant storm events, despite being a single-string architecture. This means that, to the extent possible, science data collection should continue through events such as spacecraft processor resets—events which can be common occurrences in the radiation belts. As a final measure of protection against radiation-induced upsets and to ensure that the system can operate through significant storm events, the observatory design includes an “off-pulse” architecture in which the primary bus electronics boxes (the IEM, the PDU and the transceiver) can be power cycled either by ground command or autonomously as the situation may warrant. This enables many potential faults to be cleared by removing power from the box and then restoring it to its known power-on condition. In all cases except the IEM power-off reset this also allows the spacecraft to continue recording science data, and therefore maximizes the potential for operating through a storm event.
9.2 Magnetic Cleanliness
Another key challenge for the mission is the need for both static and dynamic magnetic cleanliness. The magnetometers (both the DC Flux Gate Magnetometer and the AC Search Coil Magnetometer) are positioned away from the observatory body by means of deployable booms, but they are still sensitive to a static offset of the magnetic field (i.e. a shift in the Earth’s apparent field due to the magnetic signature of the observatory) and to dynamic changes in the apparent field, such as from periodic magnetic fields caused by unbalanced current loops within the observatory structure or electronics. This latter effect is very difficult to compensate for, and consequently great care was taken during the design of the observatory to minimize current loops in the structure and electronics regardless of the observatory’s operating mode. Static magnetic cleanliness drove materials selection—such as the use of Inconel propellant tanks, and it has also had a significant effect on ground processing, both for the integration and test of the observatories and for the integration and ground processing of the launch vehicle.
9.3 Surface Charging
In much the same way that the observatory can induce a bias in the magnetic field measured by the magnetometers, any differential charging of observatory surfaces will introduce a bias on the measurement of the ambient electrical field by the EFW instruments. To prevent this from occurring, the spacecraft and instruments are designed such that there are no (or very minimal) surfaces on the exterior of the observatories that can build up charge. In essence, all exterior surfaces are either conductive or are at least static-dissipative. This was particularly challenging in the design and manufacture of the solar arrays, which normally contain substantial areas of non-conductive grouting material. Similarly, many of the adhesives and tapes frequently used in spacecraft manufacturing are non-conductive materials, so great care had to be taken both in the design of the Observatories and in ensuring that these materials don’t find their way into the final assembled hardware.
9.4 Magnetometer as the Primary Attitude Sensor
The use of one of the science instruments as the primary attitude sensor did provide some level of program cost savings, and it minimizes the onboard hardware and removes at least one spacecraft hardware interface, but it also leads to some unique challenges. Perhaps the most difficult of these challenges is ensuring that the system can still meet attitude estimation requirements during periods of Solar storms. As discussed previously, the primary method of determining observatory attitude is by comparing the measured magnetic field to the standard model of the Earth’s magnetic field. During times of Solar storms the Earth’s magnetic field can be significantly perturbed, meaning that the actual field no longer matches the models for the Earth’s field, and the resulting measurement of the field results in an attitude estimation error. This approach also removed the “ownership” of the primary attitude determination sensor from the Guidance & Control team, and thereby replaced a hardware interface with an organizational interface. The end result is a design that is efficient and will meet mission needs, but it did impose some engineering and management challenges along the way.
9.5 Operating Multiple Observatories Simultaneously
There are also unique challenges in operating multiple observatories simultaneously. The most obvious of these is staffing mission operations and engineering teams for both observatories. For the most part, operations are designed to be sequential, though for significant periods of time—particularly during launch and commissioning—the operations of both observatories occur simultaneously. To accommodate this, dedicated teams of operators and engineers are in place for each observatories, and the operations of both spacecraft occur in separate spaces of the common RBSP Mission Operations Center. The two observatories are designed to be functionally identical and this aids in making the operation of each essentially interchangeable. This simultaneous operation is tested repeatedly prior to launch through mission simulations and other dedicated tests.
9.6 Working with a Distributed SOC System
Another challenge of the operational system is working with distributed Science Operation Centers. This approach allows convenience and reduction of cost for each of the science teams, but it requires numerous additional interfaces and relies on networks to reliably flow data to and from the MOC. One key to making this approach work was specifying a single operating system (GSEOS) for all of the SOCs to use. This greatly simplified the definition of the interface between the MOC and SOCs, and reduced the testing required to ensure that this interface works. A single MOC-to-SOC Interface Control Document (ICD) was used to define these interfaces, and a SOC working group meets regularly to discuss design, implementation and interface details. A phased set of testing that began long before the delivery of any of the instruments also helped ensure a working interface when it was needed. APL’s test-as-you-fly approach was extended here as well, as the instrument teams run much of their instrument testing during Observatory I&T from their remote SOCs.
The RBSP mission is set to explore the fundamental physics that drive changes within the Earth’s radiation belts, and the selected instrumentation and the mission design will enable an investigation of both the spatial and temporal components of these changes. The ambitious science goals and the unique environment in which the observatories operate led to some significant challenges for the design and operation of the RBSP mission, but the observatories and the ground system have been designed to overcome these challenges and meet the requirements of the mission. The science obtained by this mission will greatly enhance the community’s understanding of the processes at work in the Earth’s radiation belts, and it will allow for the development of new models that better predict the both the radiation environment and its effects on observatory hardware.
This article is distributed under the terms of the Creative Commons Attribution License which permits any use, distribution, and reproduction in any medium, provided the original author(s) and the source are credited.
- J.M. Stratton, N.J. Fox, Radiation belt storm probes (RBSP) mission overview, in IEEE Aerospace Conference, vol. 2 (2012), p. 0503 Google Scholar
- K.W. Kirby et al., Radiation belt storm probe spacecraft and impact of environment on spacecraft design, in IEEE Aerospace Conference, vol. 2 (2012), p. 0504 Google Scholar
- Radiation Belt Storm Probes (RBSP), Space Weather Interface Control Document, 7417-9100 (2012) Google Scholar