Minimize HawaiiSat-1

HawaiiSat-1

HawaiiSat-1 (also spelled Hawai'iSat-1) is a microsatellite under development by the HSFL (Hawaii Space Flight Laboratory) at the University of Hawaii, Manoa, HI. The mission goal is to provide a remote sensing capability in LEO for advanced technology and science instrumentation. The HSFL was established at the University of Hawaii for two primary goals:

• To educate students and help prepare them to enter the technical workforce

• To help establish a viable space industry that will benefit the State of Hawai'i.

The primary objectives of the mission are: 1) 2)

1) Demonstrate the ability of the HSFL to design, build, and operate a microsatellite in the 90 kg class as a platform to test new technologies

2) Support the CRATEX (C-band Radar Transponder Experiment) payload

3) Support the testing of the Thermal Hyperspectral Imager (THI) being developed at UH

4) Perform Earth imaging using the HSFL imaging payload..

The HSFL is using a core team of experienced professionals supplemented with graduate and undergraduate students to design, build, and test the HawaiiSat-1 spacecraft within a period of approximately two years from SRR (System Requirements Review) until ready for launch. To keep the spacecraft cost to a minimum, commercial-off-the-shelf (COTS) components will be used when possible. The fairly benign radiation environment of such a low altitude orbit and the use of aluminum sheeting to shield the critical avionics, make the risk of using COTS for a 2-3 year mission to be acceptable while greatly reducing the cost as compared to using space-hardened parts.

- The PDR (Preliminary Design Review) was held in June 2010.

- The CDR (Critical Design Review) was completed in Feb. 2011.

Note: Since the CDR, the project had to make a change due to funding difficulties. The CRATEX payload was removed from the manifest (it will hopefully go on a future satellite); the project is trying get other funding for the payload.

HawaiiSat1_Auto12

Figure 1: Context diagram of the original HawaiiSat-1 mission (image credit: UH)


 

Spacecraft:

HawaiiSat-1, developed at HSFL, is a microsatellite, an octagonal cylinder in shape with a launch mass of ~ 90 kg. The design life is 3 years.

Bus structure: The design of the spacecraft structure incorporates a number of primary decks supported by a system of struts (Figure 4). The general shape of the structure is an octagon to maximize the power obtained from the solar cells. The solar cell honeycomb substrate doubles as the side panels for the spacecraft and mount onto the vertical and horizontal members. The upper solar panels mount onto the zenith surface of the frame. The material to be used in the structure is Aluminum 7075-T6. A composite structure was considered, but aluminum was selected because of its reduced cost and risk/complexity. The structure is designed for accessibility, which was part of our criteria for a standard baseline bus. Helping this are removable, modular solar panels and external electrical/power feed-throughs. The HawaiiSat-1 design is kept mechanism-free for reduced associated risk and complexity.

HawaiiSat1_Auto11

Figure 2: External view of HawaiiSat-1 (image credit: UH)

There are three primary subsystems which run at all times:

1) OBCS (On-Board Computer Subsystem): OBCS is the main flight computer which runs the flight software (FSW). The OBCS interfaces with all other bus subsystems using cost effective COTS interfaces including Ethernet, RS232, and an array of analog interfaces specifically for RTD temperature sensors.

2) EPS (Electrical Power Subsystem): EPS is at at the center of the spacecraft power generation, storage, control, and distribution. A single point ground is implemented via the EPS subsystem.

3) Telecommunication (or telecom) subsystem: This subsystem handles all satellite-to-ground segment communications.

ADCS (Attitude Determination and Control Subsystem): The spacecraft is 3-axis stabilized using three magnetic torque rods and a reaction wheel for attitude control; and three sun sensors plus two inertial measurement units (each including a 3-axis magnetometer) for attitude determination. ADCS is using a new control and estimation algorithm.

TCS (Thermal Control Subsystem): TCS provides passive thermal control of the satellite system, and also has a backup heater system for atypical operations.

The three primary subsystems are designed to work together to resolve problems resulting from radiation exposure, and unforeseen software faults.

• First, the EPS provides overcurrent protected power to the entire bus. The EPS microcontroller keeps SWDTs (Software Watch Dog Timers) on all distribution lines. In an on-orbit situation, the EPS will require that the telecom subsystem and flight computer check in with EPS periodically to verify their status. If either subsystem does not check in with EPS, the SWDT expiration results in power cycling the non-reporting device. All other distribution lines have SWDTs, but are turned on and kept alive by the flight computer’s periodic requests. An expired SWDT or power-off request will result in cutting power from the device.

HawaiiSat1_Auto10

Figure 3: Bus diagram of HawaiiSat-1 (image credit: UH)

• With the OBCS in nominal operations, it will monitor and control power to all devices via EPS. Power to all flight computer controlled devices is done in either a duty cycle method, or accounted for on an energy credit system. Duty cycle controlled devices are powered on and off in intervals, or allowed to stay on at all times. An on-demand device (e.g. ADCS magnetic torque rods, or heaters) will have a finite amount of energy credits assigned to them, and deducted as energy is used by the device. Energy credits regenerate as time goes on and more power becomes available.

• The telecom subsystem provides an override command service which allows the ground segment to send specially encoded packets to power cycle the EPS and OBCS. Combined with state-of-health (SOH) beacon updates from both of those subsystems, the telecom subsystem provides the ground segment with enough information and control to recover the spacecraft from soft faults in the EPS and OBCS.

HawaiiSat1_AutoF

Figure 4: Internal configuration of HawaiiSat-1 (image credit: UH)

OBCS (On-Board Computer Subsystem): OBCS consists of two general purpose computers, responsible for the OBCS and ADCS operations, and a small dedicated processor for EPS functions. The general purpose computers are 400 MHz PowerPC MIP 405 based, running on a PC-104+ backplane. The version selected by the project has been flight tested on both the ISS and the MidStar-1 satellite (launch March 9, 2007). The dedicated EPS processor is yet to be chosen, but will need to be capable of performing sensor sampling and AD/DA (Analog-to-Digital/ Digital-to-Analog) conversion, and communication via RS-232.

HawaiiSat1_AutoE

Figure 5: Functional block diagram of the OBCS (image credit: UH)

EPS: The spacecraft generates 28 VDC unregulated current from the solar panels, which is used to charge the 28 VDC battery. The battery distributes 12 VDC to the HIP (HSFL Imager Payload) and SIP (Separation Imager Payload) instruments and an unregulated 28 VDC bus to the rest of the subsystems where the local power distribution unit regulates the voltage down to the required voltage of each subsystem (Figure 6).

The eight body-mounted solar array panels each consist of two solar array modules (strings) with 19 solar cells per module (Figure 20). The solar cells being used are BTJM (Best Triple Junction with Monolithic diode) GaAs solar cells of Emcore with an efficiency of 28%. The solar arrays generate a peak panel power of ~42 W, with average power over an orbit (with losses) of ~37.7 W. The average power margin over an orbit is ~10.7 W.

The lithium-ion battery cells of Panasonic (CGR18650) are mounted in a 7S4P (seven series, four parallel) configuration providing 246.9 Wh (8.8 Ah, 25.2 V). These batteries have been flight proven in the GeneSat-1 and PharmaSat missions.

HawaiiSat1_AutoD

Figure 6: Functional block diagram of the EPS (image credit: UH)

ADCS: The spacecraft is three-axis stabilized and capable of autonomous, closed-loop inertial pointing with an accuracy of ≤ 3º. Attitude measurement accuracy is adequate to determine where the spacecraft is pointing to 1-2º. This accuracy is achievable in real-time, in darkness or sunlight, and during all phases of the flight after deployment.

The ADCS provides the spacecraft with the capability of maintaining the +z face of the spacecraft pointing in a nadir (geocentric) direction with an accuracy of ±3º. This is the attitude required for the imaging payloads. Attitude data obtained from the spacecraft’s ADCS sensors are autonomously processed aboard the spacecraft to determine spacecraft orientation. The attitude determination is accomplished using three space-qualified AeroAstro MSS-01 sun sensors, each with 60º full-angle circular FOV providing an accuracy of ~1º, and two Microstrain 3DM-GX2 inertial measurement units (IMUs), each of which contains a 3-axis magnetometer, three accelerometers, and a rate gyroscope.

HawaiiSat1_AutoC

Figure 7: Functional block diagram of ADCS (image credit: UH)

Telecommunications (telecom) subsystem: Communication is provided by S-band and UHF-band transceivers linked to a ground station located at the Kaua'i Community College (KCC) on the Hawai'ian island of Kaua'i and other partner ground stations around the world.

The UHF radio system is of GeneSat-1 and PharmaSat satellite heritage. The UHF beacon provides amateur frequency beaconing with ASFK modulation. State of health information will be publicly available for the amateur community to decode and find out more about the satellite. It is one of the project goals to use this beacon in educational and community outreach events. The Microhard MHX-2420 is a newer version of the GeneSat MHX 2400 radio, and supports a data rate of 115.2 kbit/s. This system is designed as the primary command and telemetry radio. To keep interfaces simple, RS232 was chosen as the standard serial signaling between all telecom components.

The S-band downlink is used to transmit imagery to the ground. The radio is TBD. On onboard storage capability of 3 GB is provided.

HawaiiSat1_AutoB

Figure 8: Block diagram of the telecom subsystem (image credit: UH)

TCS (Thermal Control Subsystem): The TCS is designed to ensure all spacecraft subsystem components are thermally controlled for operation, both in sunlight and eclipse periods. The TCS will also provide SOH temperature from all critical points of the spacecraft to the OBCS. Due to the fairly benign thermal environment of a low Earth orbit, passive thermal control was determined to be sufficient. The internal power dissipation required to be handled by the TCS is from a minimum of 2.6 W to a maximum of 96.2 W. The TCS hardware consists of MLI (Multi-Layer Insulation) blankets on the interior S/C panels, appropriate surface finishing (e.g., paints), three thermostats with redundancy, heaters for critical components and temperature sensors).

The A/D board that will collect the thermal data is capable of reading 32 single-ended inputs and is compatible with RTDs (Resistive Thermal Device) sensors making is possible to have a significant amount of thermal information from the various subsystems in the spacecraft. This information is passed to the OBCS for post processing and storage. The OBCS is capable of deciding if some power line for the heaters must be turned on or off in case of any failure from the thermostats or the EPS.

HawaiiSat1_AutoA

Figure 9: Functional block diagram of TCS (image credit: UH)


 

Launch: A launch of HawaiiSat-1 is planned for 2013 on the new SPARK (Spaceborne Payload Assist Rocket Kauai) three-stage solid propellant vehicle. SPARK is based on redesigned Sandia National Lab’s Strypi ballistic rocket, aka STU (Super Strypi). The launch site is PMRF (Pacific Missile Range Facility), located on the Hawaiian island of Kaua'i.

The HawaiiSat-1 microsatellite will be deployed from PAD (Payload Adapter and Deployer), being developed by NASA/ARC (Ames Research Center). The PAD will be capable of carrying one primary microsatellite and up to 24 or 32 CubeSats or equivalents.

Orbit: Sun-synchronous near-circular orbit, nominal altitude = 550 km, inclination = 97º.

HawaiiSat1_Auto9

Figure 10: Illustration of the HawaiiSat-1 nominal attitude in its orbital path (image credit: UH)


 

Sensor/experiment complement: (THI, HIP, SIP)

THI (Thermal Hyperspectral Imager):

THI is a hosted scientific payload from HIGP (Hawai'i Institute of Geophysics and Planetology) of the University of Hawai'i at Manoa. This payload consists of an imager and computer inside a pressure vessel, an interferometry cube, and a calibration system. The configuration of the THI as it will be mounted in the satellite is shown in Figure 11. The HSFL task is to provide THI with power and data interfaces. 3)

The integration of the THI payload onto HawaiiSat-1 is the final segment of a research project funded by a NASA EPSCoR (Experimental Program to Stimulate Competitive Research) grant to develop a hyperspectral imager that is both lighter and more power efficient than previous imaging systems so as to be easily integrated into a small satellite for earth observation from orbit. The ability to acquire data from orbit will allow a more complete and uniform data set of Earth’s spectral reflectance and emittance. The data acquired will provide valuable information pertaining to environmental issues such as coral reef health, pollution and volcanic activity, all issues which directly affect the state of Hawai'i.

THI is a low cost, low mass, power efficient instrument designed to acquire high signal to noise hyperspectral remote sensing data in the longwave infrared at 250 m spatial resolution, sufficient for many applications. The instrument concept is based on on two technical advances. Most importantly, large detector arrays of infrared-sensitive microbolometers provide the sensitivity required for hyperspectral imaging. These detector arrays do not require cooling, and while not as sensitive as cryogenically cooled arrays, are sufficiently sensitive to obtain high quality spectral data when used with an interferometer. This capability has been demonstrated in an extensive series of laboratory, field and airborne tests. The spatial resolution of THI of 250 m (at 450 km altitude) is imposed by the readout rate of the detector array (30 Hz) which is required to achieve the necessary sensitivity without using image motion compensation.

HawaiiSat1_Auto8

Figure 11: Illustration of the THI instrument configuration (image credit: HIGP)

Instrument layout: THI is a converted instrument that was previously used as an airborne imager by the HIGP research team at UH. The key aspects of the imaging interferometer instrument concept are:

• THI acquires calibrated spectral radiance data in the 7.5-13.5 µm interval, using an uncooled microbolometer array

• Spectral decomposition is achieved using a interferometer comprising three mirrors and a beam-splitter in the Sagnac configuration

• COTS parts and components have been used to reduce costs

• To facilitate this, any part or component that is not designed to withstand the space environment (vacuum; radiation) is housed in a pressure vessel within which the pressure will be held at 1 atmosphere

• The instrument has been designed to meet requirements imposed (power, mass, volume, data rate) for inclusion into a 95 kg microsatellite designed by staff and students at the University of Hawai‘i.

THI measures the spectral radiance from a target using an uncooled microbolometer array of 320 x 256 pixels. The focal plane is mounted on an aluminum optical bench and housed in an aluminum pressure vessel. Light from the scene is focussed onto the array using an IR transparent lens.

Spectral decomposition is achieved using a common path interferometer, which consists of three circular mirrors and a ZnSe beamsplitter (BS), arranged in the Sagnac configuration. The rotation of the beam splitter imposes a varying optical path across the detector array which creates the interferogram. The interferometer is arranged in a box format with the three mirrors aligned at 90º to each other (Figure 12). Although Sagnac interferometers typically use a triangular path, this box configuration has a shorter total path length, thus reducing vignetting. This configuration has an aspect ratio (path length to aperture) of approximately 5:1. The rotation of the beam splitter imposes a varying optical path across the detector array which creates the interferogram.

HawaiiSat1_Auto7

Figure 12: Optical layout of the THI interferometer (image credit: UH)

HawaiiSat1_Auto6

Figure 13: Two views of the THI instrument (image credit: HIGP)

THI imaging concept: For a single frame of data, the orientation of the beam splitter and mirrors is such that the optical path difference between the reflected and transmitted beams that the interferometer imparts varies for each detector in the array (and hence scene element), and does so linearly across the sensor’s FOV (Field of View). In this implementation OPD (Optical Path Difference) is set to 5 µm/pixel, giving a range of ±800 µm. As a result, THI provides approximately 50 spectral measurements at 10 wavenumber resolution (Figure 14).

HawaiiSat1_Auto5

Figure 14: Raw frame of data acquired by a THI prototype (image credit: HIGP)

Legend to Figure 14: Vignetting and interference fringes are apparent. Light from each element of the target is phase shifted in a manner that varies linearly across the array from left to right. ZPD is zero path difference, the center burst of the interferogram.

By translating the instrument FOV in the x-dimension (using the frame of reference given in Figure 14) each scene element can be imaged at a different point in the array and hence with a different OPD. This is achieved by motion of the satellite. If the apparent motion of the platform matches the frame rate of the camera (30 Hz), then each scene element can be imaged at all possible OPDs (in this case 320). The across-track dimension of the image data set (the swath) is fixed by the y-dimension of the array (256 pixels). The length of a scene in the in-track direction is variable but must be at least as many pixels as is required for each scene element to be viewed at each possible OPD.

If such a sequence of frames is then spatially coregistered, the modulated radiance from each scene element as a function of OPD (i.e. an interferogram) can be reconstructed. This can then be transformed to a radiance spectrum using the FFT (Fast Fourier Transform). - However, prior to the generation of a calibrated spectral radiance spectrum, some processing of the raw data is required. Specifically a) a non-uniformity correction is applied to account for non-uniformity in the array response and suppress the vignetting apparent in Figure 14; b) co-registration of the individual frames to reconstruct an interferogram for each scene element, and c) calibration of arbitrary sensor units as a function of modulation frequency to spectral radiance, in W m-2 sr-1 µm-1 (Ref. 3).

THI instrument design:

The instrument is comprised of three major elements:

1) Instrument consisting of camera, optics and all electronics necessary to acquire image data

2) The calibration subsystem

3) The optical bench and pressure vessel which hosts 1) and 2).

THI instrument: The focal plane array is a FLIR Photon 320 uncooled microbolometer array of 320 x 256 pixels, which has a frame rate of 30 Hz. Transfer of data from the camera core to the THI computer is via GigE camera interface. Light from the scene is focussed onto the array using a Strix LWIR thermal imaging lens (ZnSe, 50 mm focal length, f/1.4, 93% transmissive). Spectral decomposition is achieved using a stationary interferometer, placed before the lens. The aluminum interferometer cube contains three, 3.76 mm diameter, gold coated, circular mirrors (Zerodur substrate) and a ZnSe beamsplitter. The lens is attached to a 50 mm diameter ZnSe window mounted in the wall of the pressure vessel.

All electronics required for the autonomous operation of THI are housed in the pressure vessel (PC/104). The THI flight computer uses an Intel Atom 1.33 GHz processor with 2 GB of RAM. Data is stored on a 64 GB solid state drive. Also within the pressure vessel is a) a DC-DC convertor for power conditioning, b) a fan for stirring the atmosphere within the pressure vessel.

Calibration subsystem: The calibration subsystem consists of a hot paddle and a cold paddle that can be swung into the imager’s FOV. The temperature of the paddles will be known so that the images acquired of the paddles will provide a key to the images acquired of the Earth after that calibration.

A calibration is required before every data acquisition at the least and may also be completed after the acquisitions. Before and after each imaging event, one paddle will be cooled below (and one heated above) the expected scene temperature. Each will then be inserted into the THI FOV and imaged to provide the frames required to calibrate and flat-field the scene data. For each paddle, four thermoelectric heating/cooling modules (TECs) are sandwiched between two aluminum paddles. The temperature of the top aluminum paddle (the blackbody surface) is measured by a resistance temperature detector. - The total mass of the calibration subsystem is 1.4 kg. The paddles are secured using springs in a fail-open configuration.

Pressure vessel and optical bench: The pressure vessel is made of aluminum. Preliminary finite element analysis indicates that an overpressure of 1 atmosphere (Ar or N) can be safely accommodated (i.e. factor of safety 1.55 with less than 0.479 mm displacement) by using a pressure vessel with walls 3.18 mm thick. Assuming an optical bench 6.36 mm thick gives a mass for the pressure vessel and bench of 8.24 kg. To save mass, the interferometer cube, the calibration subsystem, and all associated structures and mechanisms are attached to bench outside the pressure vessel. The total mass of the entire THI instrument is therefore 15.59 kg.

Spectral range

7.5-13.5 µm (thermal infrared)

No of bands

~30

Spatial resolution (IFOV)

330 m from an orbital altitude of 550 km

Swath width

84 km

Detector array

320 x 256 pixels (bolometer)

Data quantization

14 bit

 

 

Instrument mass, power

15.59 kg, < 90 W

Table 1: Some performance parameters of THI

The THI data have a spatial resolution of 330 m from an altitude of 550 km, with an along-track sample distance of 233 m at a sampling rate of 30 Hz (there data are therefore slightly oversampled in the along-track direction). The 256 pixel array equates to an image swath of 84 km. The along-track dimension of an image is variable. But assuming an imaging event consists of acquiring 200 frames of calibration data followed by 800 frames of scene data, and individual imaging event yields 1.1 Gbit of uncompressed data (at 14 bit quantization) in a little under 30 seconds (Ref. 3).

HawaiiSat1_Auto4

Figure 15: The THI instrument and its components (image credit: UH) 4)

 

HIP (HSFL Imager Payload):

The HIP camera has a comparatively narrow FOV and will be the primary camera used during the mission for Earth imaging.

 

SIP (Separation Imager Payload):

The objective of the SIP camera is primarily used to image the separation of the HawaiiSat-1 from the launch vehicle. However, it can also be used as a backup for the HIP imager for obtaining images of the Earth, although with lower resolution and a wider-angle lens.

Note, the cameras are not restricted to nadir imaging. The ADCS is capable of pointing the spacecraft in any direction or even to track a ground target, which provides much greater flexibility to the imaging targets of the HSFL cameras. Other than looking at off-track targets, the cameras would also be capable of pointing to celestial targets, such as calibration starts or pointing to the moon. Images can be taken by time-delayed script or real-time command on a non-interference basis. They will be stored onboard and then downlinked when convenient.


 

Ground segment:

The spacecraft will be operated at the MOC (Mission Control Center) located at HSFL The MOC uses the internet for ground station connectivity. MOC schedules all spacecraft tracking services with the ground network.

The HSFL ground station network will utilize assets at ASF (Alaska Satellite Facility), Kaua‘i Community College (HI), and Santa Clara University (CA) for satellite data download and command and control:

• Alaska Satellite Facility S-band data downlink and command and control uplink

• Kaua‘i Community College UHF data downlink and command and control uplink

• Santa Clara University S-band data downlink and command and control uplink and UHF uplink and downlink.

HawaiiSat1_Auto3

Figure 16: Overview of the mission operations process as provided by COSMOS (image credit: UH)


 

COSMOS (Comprehensive Open-architecture Space Mission Operations System):

HSFL (Hawaii Space Flight Laboratory), in collaboration with NASA/ARC (Ames Research Center) and Santa Clara University, are developing COSMOS to support this and future space missions. COSMOS features a set of software tools and hardware that is designed to primarily support the development and operations of one or more small spacecraft throughout the life cycle. COSMOS will be particularly suited for organizations with limited development and operations budget, such as universities.

The COSMOS system should be easily adaptable for adding spacecraft, interfacing with external software, and porting to MOCs (Mission Operations Centers) at HSFL, NASA/ARC, SCU (Santa Clara University) and other MOCs.

The COSMOS architecture provides a number of software tools to serve well defined operational roles and applications: 5) 6)

• MOST (Mission Operations Support Tool)

• MPST (Mission Planning & Scheduling Tool)

• GSCT (Ground Segment Control Tool)

• DMT (Data Management Tool)

• Analysis Tools

• TBCT (Test Bed Control Tool).

COSMOS is a suite of software and hardware tools that enables the operations team to interface with the spacecraft, ground control network, payload and other customers in order to perform mission operations functions. COSMOS is being designed to easily be adapted for new spacecraft or installation in new MOCs (Mission Operations Centers). Some of the basic elements of COSMOS have been developed at least to the prototype stage, while other elements are still in the conceptual stage. Although all the basic mission operations functions will be developed as part of COSMOS, it is also being designed to accept external modules (applications) as part of its “Plug-and-Play” architecture. 7)

The COSMOS system will initially be installed in the HSFL and ARC MOCs and used in support of their small LEO satellites. However, the versatility of COSMOS is demonstrated in that it is being modified to support an international lunar mission in a Phase 0 study. The primary COSMOS mission monitoring and control tool, MOST, is being used for monitoring and controlling the spacecraft, lander, and lunar rover.

HawaiiSat1_Auto2

Figure 17: COSMOS software applications (image credit: UH)

The space community is currently witnessing a universal trend rolling through space segment architectures that can be easily visualized by the steady reduction of satellite size and mass coupled with a constant increase in space systems capabilities. This unique dynamic is due to a confluence of technological factors similar to and including Moore’s Law. - Smaller spacecraft can process more data, perform more observations, and downlink more information due to continual, almost exponential advancements in computational power, solar cell efficiencies and energy storage technologies, advanced software applications, and the ability to inexpensively launch small spacecraft as secondary (or even tertiary) spacecraft on otherwise large, expensive launch vehicles.

In addition to the proliferation of these smaller, cheaper spacecraft, innovative space architectures are now also being seriously considered and even tested in space. These new architectures include cooperative, multi-spacecraft swarms or constellations that are theoretically capable of executing missions or collecting measurements and observations that are well outside of the traditional, single large spacecraft architecture and performance realms.

However, these exciting developments within the space segment are not without challenges. While the ability to reduce the size, weight and power of a spacecraft does indeed have direct cost implications, which are primarily manifested in the reduced cost of access to space, the space operations community must be prepared to support and operate these constellations or swarms of large numbers of small spacecraft in an equivalent low cost fashion. Simply scaling the traditional methods currently in use by many government or even commercial agencies would be prohibitively costly and would severely dilute the benefit of the low cost, small spacecraft platform. Therefore, similar revolutions invoking standard interfaces, high levels of automation, and other related technologies must be brought to bear on the ground segment part of the equation to fully realize the next generation of low cost, robotic spacecraft.

A fertile concept developed to stimulate this transformation is a philosophy loosely named PPMO (Plug-and-Play Mission Operations) where custom software and extensive testing can be significantly reduced or even eliminated, thus shortening development schedules, reducing overall mission risk and minimizing costs associated with the deployment and utilization of potentially many, many small spacecraft performing many diverse functions.

Table 2: Some background on the importance of PPMO (Plug ‘n’ Play Mission Operations), Ref. 7):

COSMOS architecture and design:

The central pieces of this architecture are the visualization tools, support tools, and underlying programs that produce and manipulate the data needed by the rest of the tool sets. It combines both the software and unique hardware needed to support mission operations, including an OTB (Operations Test Bed) and simulators. The simulators are all software applications, and the OTB combines simulators with spacecraft hardware where possible to mimic as closely as possible the reaction of the spacecraft to commands and operational states.

The basic philosophy behind the construction of this architecture is that its elements (tools and other programs) will be easy to port to a new location and to modify for operating with new satellites. This is enabled by being an “open architecture.” This approach means not only that the source code of its major elements and structure are available, but also that it is designed to accept external modules (which may not have source code available) as plug-ins through standard, well-defined interfaces in order to increase the overall capability of COSMOS for the desired application. - However, it is recognized that there could be ITAR (International Traffic in Arms Regulation) issues with COSMOS since it is designed to help control satellites. Therefore, a more limited definition of “open architecture” is used than the common one of having the source code in the public domain. Distribution of the COSMOS source code can be limited to only those entities (US government agencies, companies, or universities) which are allowable within ITAR restrictions. Hopefully, in the future this restriction can be relaxed as the ITAR restrictions are redefined or COSMOS is determined to not be an export-controlled product.

COSMOS is a suite of software and hardware tools that enables the MOT (Mission Operations Team) to interface with the spacecraft, ground control network, payload and other customers in order to perform the mission operations function. The basic COSMOS functional architecture is shown in Figure 18. Within COSMOS the following major functions are performed/supported: mission scheduling; contact operations; data management, mission analysis; simulations (including the OTB); ground network monitoring and control; payload operations, flight dynamics (including orbital and attitude); and support of system management and quality assurance. The description given here is for a full implementation of COSMOS to support flight operations, but some of the features may not be required by a particular MOC or mission.

HawaiiSat1_Auto1

Figure 18: Functional architecture of COSMOS (image credit: UH, NASA/ARC)

A computer is typically placed at each mission ground station to provide the interface between COSMOS and the ground station for data management (both to and from the ground station), and to monitor and possibly control the operations of the ground station. The various tools of COSMOS provide the graphical interface between the MOT and the COSMOS functions. The MOT communicates with spacecraft engineers to assist in SOH (State-of-Health) matters, such as anomaly resolution, and reports of the condition of the spacecraft and receives in return any constraints or tasking that may be required. The MOT also communicates with the various payload customers to receive reports on the status of the instruments and mission accomplishment goals, as well as to receive payload tasking requests. COSMOS uses websites or other means to allow the spacecraft engineers and customers to monitor the status of the mission directly without having to go through the MOT.

The functional flow block diagram of COSMOS is shown in Figure 19 . There are four major processes in mission operations that are supported by COSMOS:

1) Mission Planning and Analysis which also includes command sequencing and the simulators and operations testbed

2) Contact Operations which includes pre-contact operations, real-time contact operations, and post-contact operations both in the MOC and the ground network

3) Data Management which includes transfer of all data throughout COSMOS and between COSMOS external locations; data processing, such as engineering units conversion and Level 0 data processing; and data archiving

4) Mission Analysis which includes support by the MOT to analyze and trend spacecraft and ground network SOH data, orbital and trajectory data, and mission accomplishment data to help determine the mission success MOE s(Measures of Effectiveness). The results of the Mission Analysis process are fed back to the mission planners, spacecraft engineers (especially for resolving spacecraft anomalies), mission management, and customers.

HawaiiSat1_Auto0

Figure 19: Functional block diagram of COSMOS (image credit: UH, NASA/ARC)

Overview of COSMOS tools:

The tools of COSMOS are the software applications with which the human operators interact to control COSMOS and the mission operations processes.

CE (COSMOS Executive): There needs to be a way to monitor and control the operation of the entire COSMOS system and possible to launch or terminate various COSMOS tools. The CE fulfills this function. It shows which elements of COSMOS are running, which mission/spacecraft they are controlling, their current status and level of activity. From the CE you can start up any of the COSMOS tools and transfer into that tool if desired as a new computer session, which will put the CE into background mode, possibly within a separate window if desired. The CE also provides another function – it is the way to monitor multiple satellites and ground stations simultaneously from a single tool.

MPST (Mission Planning and Scheduling Tool): The MPST converts mission status and tasking inputs into executable command loads or sequences, schedules, and timelines. The MPST provides a top-level interface to the mission planner (human) and consists of the following major tools: Scheduler (produces the long- and short-term plans and schedules), Timeliner (produces the timeline), and Command Script Generator (produces the command script or sequence that is uploaded to the spacecraft). An example of the application of the “Plug-and-Play” paradigm in COSMOS is the inclusion of the independent mission planning module, developed by Riverside Research, called the ACPT (Automated Collection Planning Tool). This tool is built on AGI’s STK engine and is being used for the DoD’s MTI (Multispectral Thermal Imaging), TacSat-3, and other missions. This optional module provides a powerful addition to the MPST to help plan remote sensing missions while considering constraints, criteria, priorities, and resource utilization.

OTB (Operations Test Bed) and Simulators: The COSMOS OTB uses an open-source system architecture that integrates hardware and software components and tools to operate a low cost Satellite System Simulator (e.g. FlatSat) which can be integrated into the MOC setup for command scripting testing, personnel training, mission rehearsals and anomaly resolution. The OTB has tools for satellite technology integration and development that allows for cheaper satellite subsystem integration and testing. The OTB tools are based on COTS that are affordable to universities while some tools are being developed under the COSMOS project using proven standards and made available to the small sat community. The OTB is part of the four major processes in mission operations that are supported by COSMOS, namely the Mission Planning and Scheduling, Real-time contact operations, mission analysis, and anomaly resolution.

MOST (Mission Operations Support Tool): This is the primary element of COSMOS and is the visualization tool designed specifically for supporting real-time operations. However, MOST can also be used for supporting the following major operations functions:

1) spacecraft & payload monitor & control

2) mission planning

3) simulations & rehearsals

4) trending & analysis

5) anomaly resolution.

MOST is based on the LUNOPS program that was developed to support both LEO and lunar operations for the Clementine mission in 1994. Features of LUNOPS were incorporated into the design of some JPL mission operations software.

GSCT (Ground Segment Control Tool): This is a graphical interface for monitoring and controlling the ground network. GSCT includes all the pertinent information of each ground station, such as location, antenna type, contact information as well as a status for the ground station. The GSCT displays the ground station configuration for an upcoming contact (e.g., which files are waiting for upload, frequency setting, ephemeris file used for open-loop tracking). It also allows monitoring of the ground station status during a contact, displaying the antenna pointing angles, actual versus predicted antenna pointing, carrier signal detection and lock status, signal strength and data rate, etc. GSCT also allows the user in the MOC to send commands to the ground station as required. The GSCT is designed to view the ground segment/network data in a manner that allows the user to understand the information quickly and easily. It is possible to view all of the ground stations on a map with their statuses easily discernable. The input to GSCT comes from users, MOST and the customers. The output goes to the customers and the DMS (Data Management System).

DMT (Data Management Tool): Files are the primary method of data flow between elements of COSMOS. Central storage and dissemination of the files is through a DMS whose function is to:

• Accept files for delivery to other parts of the system

• Store files for long term access

• Provide access to stored files

• Forward files to other parts of the system.

The DMS will be able to manage multiple spacecraft, distinguishing between them by spacecraft designator. It stores both informational data, and longitudinal data, such as payload data and telemetry. Longitudinal data are accessible by date of creation. The DMS is split between a DMA (Data Management Agent), and a DMT (Data Management Tool). The DMA stores files in a simple directory structure, receiving them via standard file transfer protocols. These files are available either through the local file system, in the case of the MOC, or through standard file transfer protocols. Control of the DMA is through a GUI-based control program, the DMT. The DMT allows monitoring and control of the DMA, as well as adding additional features for analyzing data storage and flow.


1) Luke Flinn, Lloyd French, Leonard Gouveia, “Hawaii Space Flight Laboratory,” July 19, 2010, URL: http://hsfl.hawaii.edu/HSFL_Overview_071910.pdf

2) Trevor C. Sorensen, Lloyd French, Jeremy K. Chan, William K. Doi, Elizabeth D. Gregory, Marcelo H. Kobyashi, “Hawai'iSat-1: Development Of A University Microsatellite For Testing a Thermal Hyperspectral Imager,” AIAA Space Conference & Exposition 2010, Anaheim, CA, USA, Sept. 27-30, 2010, paper: AIAA-2010-8922

3) Robert Wright, Paul Lucey, Keith Horton, Mark Wood, Harold Garbeil, Sarah Crites, “The Thermal Hyperspectral Imager: an instrument for remote sensing of Earth's surface, oceans, and atmosphere, from a micro satellite platform,” Proceedings of IAC 2011 (62nd International Astronautical Congress), Cape Town, South Africa, Oct. 3-7, 2011, paper: IAC-11-B4.4.11

4) Brian Taylor, “Innovative Satellite Launch Program,” Jan. 14, 2011, URL: http://www.hawaii.edu/offices/op/innovation/taylor.pdf

5) Trevor C. Sorensen , Eric J. Pilger, Mark S. Wood, Miguel A. Nunes, “Comprehensive Open-architecture Space Mission Operations System (COSMOS), Overview,” PPMO (Plug and Play Mission Operations) Workshop, San Jose, CA, USA, May 16-17, 2011, URL: http://ppmo.arc.nasa.gov/media/Nunes-1.pdf

6) Trevor C. Sorensen, Eric J. Pilger, Mark S. Wood, Elizabeth D. Gregory, Miguel A. Nunes, “Development Of The Mission Operations Support Tool (MOST),” SpaceOps 2010 Conference, Huntsville, AL, USA, April 25-30, 2010, URL: http://hsfl.hawaii.edu/AIAA-2010-2230-245.pdf

7) Trevor Sorensen, Bruce Yost, Joan Differding, Eric Pilger, Miguel Nunes, “Plug and Play Mission Operations,” Proceedings of the 2012 IEEE Aerospace Conference, Big Sky, Montana, USA, March 3-10, 2012


The information compiled and edited in this article was provided by Herbert J. Kramer from his documentation of: ”Observation of the Earth and Its Environment: Survey of Missions and Sensors” (Springer Verlag) as well as many other sources after the publication of the 4th edition in 2002. - Comments and corrections to this article are always welcome for further updates.