Minimize TacSat-4

TacSat-4 (Tactical Satellite-4)

TacSat-4 is a US technology demonstration minisatellite and a follow-up mission within the ORS (Operational Responsive Space) program of DoD, representing a partnership between three military service branches. The project is being funded by a joint partnership between ONR (Office of Naval Research) and OFT (Office of Force Transformation). TacSat-4 has several ORS system level objectives including using a prototype bus to mature spacecraft bus standards for acquisition and to fly in a “low” highly elliptical orbit (HEO), enabling a new set of ORS missions that require dwell, such as communications. 1) 2) 3) 4) 5) 6)

The payload capability selected in October 2005 includes COTM (Communications-on-the-Move), BFT (Blue Force Tracking), and Data-X (Data-Exfiltration). The COTM capability provides UHF legacy radio support (10 channels) and a Mobile User Objective System (MUOS)-like capability. The BFT capability collects existing UHF devices with tasking priority expected for underserved areas in the ground segment. The Data-X capability focuses on data collection from Navy buoys, which are typically remotely located on the seas and in littorals.

Note: In May 2007, the program management was transferred from OFT to the newly created ORS Program Office, located at Kirtland AFB.

Overall mission objectives:

• Demonstration of a high dwell time ORS capability via a HEO (Highly Elliptical Orbit)

• Evaluation of Phase 3 system level bus standards in a realistic I&T, launch and flight operations environment

• Demonstration of mobile data communications services. Particular goals are: Provision of TacSat/ORS COTM (Communications-on-the-Move) radio capability (legacy and MUOS-like wideband) where MUOS (Mobile User Objective System). The goal is to arrive eventually at the JTRS (Joint Tactical Radio System) which enables various radio types to communicate with each other, leading to a family of interoperable, software-defined radios.

• Collection of BFT (Blue Force Tracking) devices in underserved areas

• Perform buoy/sensor Data-X on Moderate-to-High Power Transmissions.


Figure 1: Overall system architecture of TacSat-4 (image credit: NRL)




The TacSat-4 spacecraft consists of the “standard bus” and the COMMx (all-communications) payload; each is being designed by a separate team. The standard “prototype” bus design involves multiple government, industry, and academia participants assembled into an Integrated System Engineering Team (ISET). ISET was established in 2005. Major government/academia participants are NRL/NCST (Naval Research Laboratory/Naval Center for Space Technology) and JHU/APL (Johns Hopkins University / Applied Physics Laboratory). The industrial team for the spacecraft bus consists of the following participants: Microcosm, ATK/Swales, MSI (MicroSat Systems Inc.), General Dynamics, Loral Space & Communications, Design Net Engineering, Orbital Sciences Corporation, Boeing, AeroAstro, and Raytheon. 7)


Figure 2: Illustration of the deployed TacSat-4 spacecraft (image credit: NRL)

Standard bus for ORS satellites:

The main goal within the ORS (Operationally Responsive Space) strategy of DoD is to develop new revolutionary operational concepts and technologies for the conducting military operations. The vision embraces two fundamental elements:

1) Operational systems that can be quickly deployed to meet military needs

2) S&T (Science and technology) systems that use rapidly developed, cost-effective standard systems to develop new technologies through experimentation.

So far, much of the focus of individual programs has been on developing S&T systems that attempt to provide a spiral development capability towards operational systems that will be components of an ORS acquisition. The DoD vision hopes to bridge the gap between S&T systems and operational systems by using aspects of the S&T experiments as inputs to future operational systems. 8)

The “Standard Bus Initiative” represents a major aspect of the ORS concept which started in the spring of 2005. The Phase III objectives of ORS are to develop and mature bus standards in an open environment with broad government, industry, and academia participation. This was accomplished by forming a national system engineering working group with the US small satellite industry to establish and maintain ORS bus standards to include both technical and business factors.


Figure 3: ISET requirements flow (image credit: NRL, JHU/APL)


Figure 4: Phase 3: Standard bus architecture development - prototype to production (image credit: JHU/APL)

The ORS Phase III Bus Standards program continues to pursue completion of the primary objectives: 9) 10) 11) 12) 13) 14) 15) 16)

3) to establish a national systems engineering working group with the US laboratories, small satellite industry, government, and academia to develop primary interface standards for a class of ORS spacecraft

4) to validate and/or refine a subset of those standards by prototyping an ORS bus to be used for the TacSat-4/COMMx mission.

Standard bus phases 1 through 4:

• Phase 1: Team building and analysis

• Phase 2: Avionics and interface standards initial demonstration on TacSat-3

• Phase 3: Standard bus prototype development

• Phase 4: Standard bus production phase.


ISET bus standards documents:

Four documents establish the ORS Phase III bus standards and represent the final deliverables from the Phase III team to the Phase IV team as shown in Figure 5 (Ref. 13). The ORS Office at AFRL is responsible for the overall ORS system.


Figure 5: ORS bus standards documents (image credit: NRL)

1) Mission requirements and CONOPS (Concept of Operations) document: The primary focus of this document is to outline the orbital environments, envelope the multi-mission support requirements, establish concepts for tactical support and define concepts for operational responsiveness and develop scenarios.

2) The GBS (General Bus Standard) document contains general programmatic requirements for interactions of the vehicle manufacturer with the government, RF communications interfaces, interfaces with the ground operators for the spacecraft command and control, launch vehicle interfaces, bus functional and performance requirements, ground support equipment and integration facility requirements, and mission/quality assurance provisions.

There are many performance requirements that the spacecraft bus must meet which are contained in the ORS Payload Developers Guide (ORSBS-003) and the Data Interface Standard (ORSBS-004). These two documents in combination with the GBS document represent a complete set of requirements for the spacecraft bus.

3) The PDG (Payload Developers Guide) presents the envelope of capabilities and the requirements for support of the selected range of potential missions. It identifies the necessary performance requirements, interface definitions, and general ORS philosophies needed by mission designers and payload developers to be compatible with the ORS spacecraft bus and launch capability. The PDG intended to be a standalone document from the payload provider perspective.

The support accommodations for the payload contained within this document were derived from an enveloping process conducted by the ISET. In order to develop effective standards, it was necessary for the ISET to research the mission needs and payload support requirements across a wide range of potential missions that were representative of a typical mission for the ORS program. Table 2 shows the capabilities available to a potential payload.

Payload mass, volume

175 kg, 0.62 m3

Orbit average power, peak power

200 W, 700 W

Orbit position knowledge

90 m (3σ)

Attitude knowledge, attitude control

0.017º (3σ) each axis, 0.05º (3σ) each axis

Slew rate of spacecraft

2.0º /s each axis full attitude performance

Spacecraft SB operations data rate

5 Mbit/s

Tactical downlink data rate

UHF typical 9-56 kbit/s and/or
CDL (Common Data Link) at 274 Mbit/s (max)

Payload data storage

1 Gbit (max)

Thermal dissipation to SB

60 W

Table 1: Supported payload capabilities of the standard bus

4) The Data Interface Standards document defines the information exchange protocols, data transport envelopes, message structures and data fields for the bus/payload interface and the space/ground interface. Both the bus/payload and bus/ground interfaces conform to CCSDS recommended standards.

The bus/payload interface minimizes dependencies on the link and hardware characteristics. All transport and message protocols are identical for both types of standardized Bus/Payload communication links comprised of SpaceWire and RS-422/HDLC. The interface definition establishes a balanced approach for the bus/payload interface to eliminate stringent timing and interface activity requirements. Either the bus or the payload can initiate or reestablish communications without regard to the state of either side of the interface.

The bus/ground interface definition extends the payload communication services to the ground and provides for the direct communications required for bus control and monitoring. The ORS Phase III bus fully implemented the bus/payload and bus/ground interfaces. The COMMx payload utilized the RS-422/HDLC link and implemented a proper subset of the interface standards. The UIE (Universal Interface Electronics) R&D payload component, exercised the SpaceWire link and implemented a proper subset of the interface. The bus/payload interface allows for the payload to pick and choose the services it requires and does not require implementation for handling all published message exchanges.

Prototype bus implementation:

The prototype bus, referred to as ORS Phase 3 bus, was developed jointly by the JHU/APL and NRL teams. The general layout of the bus structure is shown in Figures 6, 7, and 8. 17)

Thermal design: The nature of the envisioned ORS operational system, in which buses and payloads can be developed separately and integrated at the launch site, requires that the bus be designed such that it is effectively isolated from the payload and therefore able to operate with a range of payload designs. Thus, this prototype maximized thermal isolation as an approach to handle various payloads designs. The physical connection between the payload and bus required conductive isolation. The thermal design must also account for the fact that the use of radiators on the bus may expose nonblanketed areas to thermal radiation from the payload, and the bus itself could affect payload performance (Ref. 13).

The thermal subsystem implementation passively controls the internal bus temperature, specifically the propulsion lines and tank, and does not use heaters directly on the propulsion lines.


Figure 6: Two views of the ORS prototype bus (image credit: JHU/APL, NRL)


Figure 7: Photo of the flight bus with a payload mass simulator on top (image credit: NRL, JHU/APL)


Figure 8: Photo of the TacSat-4 bus structure and some electronic units (image credit: ONR)

The OBC of the ORS standard bus is a non-redundant modular design composed of an RHC-3001 based SSPM (Standard Spacecraft Processing Module) from Harris, an 8051 based CTC (Command and Telemetry Controller Module), the API (Attitude and Propulsion Interface Module), a PAI (Processor and Interface Module), a PDH (Payload Data Handler) module and a PSC (Power Supply Module).

The SSPM utilizes a VME bus, is rated at > 1 MRAD and has a published bandwidth of 31 Dhrystone MIPS. The PAI module provides SSPM processor interfaces to the star tracker, IMU (Inertial Memory Unit), CTC and the CEASE (Compact Environmental Anomaly Sensor Experiment). The PAI also provides 256 KB of PROM based boot storage for the SSPM. The SSPM is externally and dynamically configured by the CTC to boot from internal EEPROM or the PAI based PROM. The PAI distributes timing within the CDE (Command and Data Electronics).

The PDH module implements the 512 MByte EDAC protected SDRAM based SSR (Solid State Recorder), 2 x RS-422/HDLC payload interfaces, 2 x SpaceWire interfaces, the transponder wideband return link interface, 32 x DMAs, external CDE time distribution, and a VME interface. The SpaceWire interface utilizes the NASA/GSFC VHDL SpaceWire link core, which is freely available to U.S. users, as is a SpaceWire router core. 18)


Figure 9: Illustration of the command and data electronics module layout (image credit: JHU/APL, NRL)


Figure 10: External interfaces of the CDE (image credit: NRL) 19)

Spacecraft mass, power

468 kg, 1000 W

Payload power

200 W average, 610 W peak

Design life

-1 year ONR funded operations
-Design goal: Planning calls to operate the spacecraft for 3 years

Communication payload capability

- Data-X (Data-Exfiltration - focuses on data collection and relay from Navy buoys)
- BFT (Blue Force Tracking)
- COTM (Communications-on-the-Move) provides 10 UHF channels with:
a) Legacy radio & IP netted support, b) MUOS-like wideband capability, CDMA mode

Table 2: Some parameters of the TacSat-4 spacecraft


Launch: The TacSat-4 spacecraft was launched on Sept. 27, 2011 on a Minotaur-IV+ vehicle (OSC) from the Kodiak Launch Complex (KLC), Kodiak Island, Alaska. 20) 21)

The original launch date was fall 2009, however it was delayed several times to Q4 2010 because of Minotaur-IV technical issues and changing DoD mission priorities, then to may 2011. - In October 2009, the NRL engineers completed the TacSat-4 spacecraft (Ref. 5).

Orbit: A “low” HEO (Highly-elliptical Earth Orbit). Long dwell times (2 hours +) or constant coverage of a theater (region) is required. The nominal orbit is 700 km x 12.050 km, inclination = 63.4º, period = 4 hours. The apogee is located at 30º N latitude (Molniya type orbit).


Figure 11: TacSat-4 first orbit illustration (image credit: NRL)

Early flight operations: The nominal LV (Launch Vehicle) insertion orbit for TacSat-4 was 185 km by 12,050 km. The low initial perigee heightened concerns that resulted in the implementation of a perigee raising burn at apogee on the first orbit. In fact, most of the critical events occurred during the first half of the first orbit; including spacecraft power up and activation, checkout burn, first apogee burn, and solar array deployment and checkout. A pictorial summary of the first orbit events is shown in Figure 11 (Ref. 28).


Communication bus:

Studies were performed with regard to proper technology implementation for a standard ORS communication bus prototype. The choices were between Firewire, SpaceWire, and Ethernet, taking into consideration the performance metrics for each candidate system (including: system availability, space heritage, data rates, flexibility/expandability, power, complexity, mass/node, etc.).

The SpaceWire link on TacSat-4 connects the PDH (Payload Data Handler) module in the CDE (Command and Data Electronics) on the bus side with the UIE (Universal Interface Electronics) on the payload side.

The TacSat-4 SpaceWire link has two nodes: The PDH on the spacecraft bus side, and the UIE on the payload side. They are connected by a non-standard SpaceWire cable to facilitate ease of rapid depot integration of the bus and payload. CCSDS Space Packets and other CCSDS formats are used on top of SpaceWire. 22) 23) 24)


Figure 12: The SpaceWire concept on TacSat-4 (image credit: NRL)

The UIE, developed at MSI, is a versatile multifunction unit that employs SpaceWire and RS-422 interfaces. Its different interfaces and various configurations allow it to perform as a protocol translation, power distribution, data storage, or telemetry collection and consolidation node.

The UIE employs the Leon-3 processor (Gaisler Research) and SpaceWire core in an Actel RTAX2000S FPGA and also includes a Xilinx Virtex II FPGA for mission-specific configurations. The SpaceWire bus port is supplied by the PDH, a module in the CDE (Command and Data Electronics) box. An additional ground support equipment SpaceWire port is provided as well; this could be used to support another SpaceWire device in the future. The PDH also includes RS-422 ports, a direct link for a wide band downlink, and 512 MB of data storage.

The Universal Interface Electronics (UIE) box supplies the SpaceWire port on the payload side. The UIE provides numerous other capabilities including other SpaceWire ports, RS-422 ports, analog and digital I/O, data storage, and power switching. The UIE translates data from the ODTML (Ocean Data Telemetry Microsat Link).


Figure 13: Block diagram of the PDH (image credit: NRL)


Figure 14: Block diagram of the UIC (image credit: NRL)


Figure 15: Photo of the completed spacecraft at integration (image credit: NRL) 25)


Figure 16: TacSat-4 ready for fairing encupsulation (image credit: NRL)


Figure 17: Artist's rendition of the deployed TacSat-4 spacecraft (image credit: JHU/APL)



Status of TacSat-4 mission:

• September 2013: The TacSat-4 mission delivered successful flight hardware for on-orbit test, evaluation, and military utility assessment. This small (450 kg) satellite demonstrated SATCOM performance that matches or beats current geosynchronous satellite in terms of radio frequency link margin; for voice TacSat-4 is at least two times (3 dB) stronger and for all uplink signals it is at least 4 times (6 dB) stronger. The program also demonstrated many elements of the ORS concept such as maturing the ORS bus standards, developing an enhanced Minotaur-IV+ launch vehicle capability, demonstrating the first long-dwell orbit and mission for a small satellite, and highly automated command and control as well as mission planning. The spacecraft is currently on orbit and available for experimentation through the end of September 2013. 26)

- While the experimental portion of TacSat-4 was very successful, the fiscal challenges prevalent today prevented a transition of the capability to operational status. Follow-on efforts have been studied and should the need arise a TacSat-4 like constellation could be procured and provide utility to any number of users. In addition, the ITU filing is complete for a follow-on constellation of up to 6 satellites continuously for the next 40 years.

- The TacSat-4 experimentation and JMUA activities performed have shown TacSat-4’s ability to provide SATCOM for a wide range of Users and applications. Successful SATCOM was achieved for soldier-to-soldier, USCG (U.S. Coast Gourd) ship-to-ship, USCGC ship-to-communications station, USCG Cutter-to-SIPRNet (Secure Internet Protocol Router Network), Marine-to-network, Marine-to-High Mobility Multipurpose Wheeled Vehicle (HMMWV), ship-to-Marine, and sub-to-shore. All testing used standard SATCOM equipment. Voice, chat, file transfers and other network applications were successfully performed.

- The USCG has demonstrated experimental and operational use of TacSat-4 on several of their cutters and their helicopters. USCG added a network ground terminal at the Kodiak Communication Station (COMMSTA) which enables SIPRNET voice and data communications to ships in the Bearing Straights all the way back to their Alameda California station. USCG has tested TacSat-4 with Cutters JUNIPER, HEALY, ALEX HALEY, HICKORY, MUNRO, BERTHOLF, SYCAMORE (voice), and SPAR (voice). Many of these have had SPAWAR’s SATCOM “Fly Away Kits” installed on them as well. The USCGC Healy even used TacSat-4 while returning from its escort and ice breaking mission assisting a Russian tanker in delivering emergency fuel to Nome, Alaska.

- Transition to operations: The Commander, USSTRATCOM has the authority to transition TacSat-4 to operations if certain criteria are met including demonstrated military utility, Operations & Maintenance funding source, and an executable operational concept of operations. The United States Strategic Command J6 decided not to pursue transition to operations of the TacSat-4 satellite due to the lack of a funding source. While TacSat-4 did not transition to operations, the capability demonstrated and the unique benefits inherent in the mission design will provide benefits to the government for years to come. Transitioning experimental missions to operations is difficult and rare due to many factors necessary to ensure reliability for the warfighter. TacSat-4 met the standards for transition but due to economic factors will remain an experimental satellite available for use with additional funding (Ref. 26).

• The TacSat-4 spacecraft and its payload are operating nominally in 2013. 27) TacSat-4 is now in its second year of on-orbit demonstrations with funding from the ONR (Office of Naval Research).

• Summer 2012: The first year of operations is for experimentation, user training, and the ORS Office lead JMUA (Joint Military Utility Assessment). Experimentation is well underway with users including the US Army SMDBL (Space & Missile Defense Command Battle Laboratory), the US Navy’s Trident Warrior 2012 experiment, SPAWAR (Space and Naval Warfare Systems Command), US Coast Guard, and US Marine Corps. International participants include the United Kingdom and Canada through the TTRDP (Trilateral Technology R&D Project). Transition to operations is being worked in detail during the first year of flight operations as specific users are identified. 28) 29)

Some end user results:

- The US Army SMDBL has been leading the Joint utility assessment, particularly in the areas of COTM and VMOC, on behalf of the ORS Office. They have conducted evaluations using multiple legacy radios (PRC-117F/G, PRC-148, PRC-152, PSC-5D, PDA-185) and antenna configurations (eggbeater, spitfire, x-wing) that have allowed them to identify the best combinations of equipment. They have performed evaluations in mountainous and urban terrains, on foot and in moving vehicles, with several excellent tests. SMDBL has also demonstrated the ability to send large data files, exercised a “time sensitive” task, i.e., a request submitted less than 24 hours before execution, and proved that TacSat-4 can be used to uplink data collected by UGS (Unattended Ground Sensors). The connections to non-SATCOM “whip” antennas was also performed by the SMDBL. However, the results for these non-SATCOM antennas have been only 20-40% successful, which is not acceptable for operational end users

- SPAWAR has performed TacSat-4 testing, and verified that the system works in accordance with the Joint Interoperability Testing Command standards that apply for legacy SATCOM with certified radios. Fundamentally, SPAWAR was verifying that TacSat-4 can augment UHF SATCOM for mobile users using standard SATCOM equipment including SATCOM omni-directional antennas.

- The formal Navy utility assess occurs in Trident Warrior 2012. In this experiment TacSat-4 is being used to provide SATCOM between many platforms: between a Navy ship and Marines on shore, a US Navy ship to Allied ship, sub-to-shore, sub-to-Marine, and Marine-to-SIPRNET via the TacSat-4 Portable Ground Terminal. This testing is exercising much of the US Navy’s UHF SATCOM equipment to verify TacSat-4 works with it as expected.

- TacSat-4 was used by the US Coast Guard Cutter Healy as it returned from the Bering Sea from its ice breaking mission with the Russian tanker Renda to delivery emergency fuel supplies to Nome, Alaska. The US Coast Guard has also begun testing TacSat-4 with their helicopters.

- The USAF (US Air Force) CEASE payload, a radiation experiment, is showing radiation levels in TacSat-4’s orbit are higher than the models had predicted, especially regarding proton levels. The USAF is working to update the current radiation models with this new data.

- The spacecraft bus was built to standards that were still evolving. The battery was designed for rapid, in the field replacement without spacecraft disassembly. The flight of the TacSat-4 battery also qualified a new lithium ion cell design for the space community (Ref. 28).

So far, the TacSat-4 mission delivered successful flight hardware for on-orbit test, evaluation, and military utility assessment. The program also matured the ORS bus standards, and demonstrated many elements of the ORS concept. The experimentation and utility assessment are being performed during the first year of operations to verify the utility of the TacSat-4 mission and further refine several of the ORS concepts of operation. The decision to transition TacSat-4 into full operations will be made once the utility assessment is complete (Ref. 28).

• In January 2012, TacSat-4 enabled a polar region SatCom experiment. The U.S. Coast Guard Cutter HEALY (the Coast Guard's only polar icebreaker) successfully experimented with NRL's TacSat-4 communications satellite, Jan. 24, 2012, by communicating from the Bering Sea off the western coast of Alaska to Coast Guard Island, Alameda, CA, USA. The experiment was the first in a series of planned steps that aim to demonstrate TacSat-4's utility in the polar and arctic regions. 30)

• The “low” HEO (Highly Elliptical Orbit) of TacSat-4 demonstrates technologies and satellite communications techniques, providing military satellite communication support centers better links to underserved satellite users and areas. 31)

• By the end of the first week of flight operations, the spacecraft command and control automated operations mode was being phased into use. The basic pass plans, activities done in view of a ground station antenna, were being performed using the monitor mode, where the system automatically plans the pass with an operator watching and approving each step. The fully automated mode was being used by week two for known operations and continues to be defined based on actual, vice predicted, subsystem operations (Ref. 28).

• September 30, 2011: The umbrella-like antenna on the U.S. Navy's experimental TacSat 4 communications satellite has popped open and begun relaying voice messages a week after launching from southern Alaska, according to mission officials. The antenna (Figure 18) opened on Sept. 30, 2011 three days after launch, and is working well. 32)



Experiment complement: (COMMx, LHP, TSSCE, CEASE)

COMMx payload:

COMMx is the primary payload of the TacSat-4 mission. COMMx, developed by NRL, is the first payload developed for use with the ORS Phase 3 standard bus. The requirements for the bus and payload were NOT written to suit the payload or the mission as would be typical on most spacecraft. Rather, the requirements were written for a single bus and multiple payloads that would support a variety of TacSat missions. This fact complicated the development of COMMx and in some cases increased the cost and schedule of the COMMx development. 33) 34) 35)

The key requirements of COMMx payload, affecting the TacSat-4 spacecraft bus design, call for the following limiting conditions:

- 200 W orbit average power provided by the bus for payload operations

- a payload stiffness requirement of 50 Hz or greater

- the requirement for the payload to be thermally isolated from the bus.

The COMMx payload consists of a primary cube structure of about 0.93 m side length, mounted to a reflector dish of ~3.75 m in diameter, and followed by cone structure of ~ 1.85 m in length which serves as the UHF feed. The following goals had to be met:

• The dish reflector represents a completely new technology design (3.66 m aperture antenna) which takes advantage of the loose mechanical tolerances allowed when operating at UHF frequencies. These relatively loose tolerances allow an ORS class cost reflector to be achieved.

• PIM (Passive Intermod) test set: To test the COMMx payload for PIM, a test set was developed which is capable of testing for PIM across a broad portion of the UHF spectrum. This PIM test set is likely the only one in the country capable of testing for PIM across such a broad portion of the UHF spectrum with sufficient sensitivity.

• Multipactor test set: This test set was developed which is capable of testing all the COMMx high-power UHF hardware (UHF feed, quadripole, circulator, cables, loads and filters) for the Multipactor.

• Primary structure: Designed, analyzed and integrated the lightweight primary structure that meets 50 Hz stiffness requirement for a 180 kg payload.


COMMx antenna:

The COMMx antenna is a parabolic reflector designed to operate over a frequency range of 240-420 MHz. The antenna was designed so that the surface could deviate from a perfect parabola by up to 6.35 mm root mean square (rms). This rms requirement, which is very loose compared to most standard reflectors, is possible because of the frequency range over which the antenna operates. The antenna mass allocation was 27.2 kg, with a stowed structural first mode greater than 60 Hz, and a deployed structural first mode greater than 5 Hz (Ref. 5).

The entire TacSat-4 spacecraft including the stowed antenna must fit within the fairing envelope of the Minotaur IV launch vehicle. The orbit for TacSat-4 requires the unshielded antenna to survive 100 MRad of TID (Total Ionized Dose) radiation, and to survive on-orbit temperatures in the range ±150º C. Finally, the antenna must be capable of transmitting and receiving multiple carriers simultaneously. In order to meet this requirement the antenna was designed to be low PIM (Passive Intermodulation), which is common in large, commercially available deployable antennas. The effect of PIM operationally is to raise the noise floor of the antenna, reducing its performance to unacceptable levels. PIM is generated by loose or “dirty” metal to metal contacts in the RF field. Constructing a low PIM reflector required that metal to meta contacts be avoided if possible, and closely analyzed where necessary.

A consequence of the 200 W limit for the COMMx payload (ORS phase 3 bus standards) was that the RF electronics had to be customized for a significantly improved efficiency to meet this goal - rather than using COTS components as planned. In addition, a state-of-the-art heat-pipe thermal control system loop had to be installed to meet the power limits of the COMMx payload.


Figure 18: Photo of the deployed UHF flight model antenna on the COMMx payload (image credit: NRL)

The goal of the TacSat-4 antenna design was to take advantage of the loose rms requirements in order to reduce the complexity and cost of the antenna. A gore approach was selected using several smaller reflector pieces that were joined using capacitive coupling to form a single reflector while avoiding any metal-to-metal contacts. This novel approach, for which a patent has been applied, used a Kapton-copper flex circuit material. Each gore is a sandwich with Kapton on the outsides and a soft copper grid in the middle. The copper thickness was selected so that it was three skin depths over the frequency range of the antenna, allowing the gores to act as an RF reflector. It was important to minimize the amount of copper used in the design in order to achieve the required mechanical performance of the gore material as well as to minimize the mass of the reflector while allowing the material to be stowed. Flex circuits have previously been used in space, but not in this manner. To gain confidence in and to qualify the material, several small material samples were put through thermal, vacuum, and radiation tests. Additionally, the Kapton® material was attached to a scaled antenna model to evaluate its behavior during the stowing and deploying processes. As a result small perforations were added to the gores to allowing out of plane bending, and to relieve stress concentrations when stowing the reflector. The grid spacing and hole size were limited by RF requirements on the reflector. The availability of raw material drove the gore size and the number of deployable ribs. Even though the gores were sized to fit within commonly available widths, only a limited number of vendors were capable of processing parts of this size. 36)

The low PIM requirements on the antenna forced a capacitive coupling approach throughout the antenna design. This capacitive coupling relies on an even preload being maintained on all RF joints including the joints between individual gores. Non-metallic fasteners hold the reflector gores to each other and the ribs to maintain the equal preload required across the entire joint.

An engineering development unit (EDU) antenna was fabricated and fully tested in order to gain confidence in the antenna design. Testing included in-air deployments, baseline RF patterns and PIM measurement, surface RMS measurements, three axis quasi static loads, random vibration, thermal vacuum (TVAC) cycling with deployment testing, post environmental RF patterns, PIM measurements, and surface mapping.

To stow the antenna during launch, a strap is tensioned around the antenna, located about two thirds toward the top, using a Frangibolt for preloading the strap and later for releasing the strap (Figure 15).

The flight model (FM) antenna (Figure 18) was built following the completion of all EDU testing. The flight antenna incorporated the lessons learned on the EDU antenna. The FM antenna went through the same mechanical and RF testing as the EDU antenna. This included in-air deployments, surface mapping, RF performance testing, quasi-static and random vibration testing, TVAC testing with deployments, final surface mapping, and post environmental RF performance testing. The antenna passed all tests, and was delivered for system integration and testing. The FM antenna has a measured surface accuracy of 8.13 mm rms, and has seen a total of 30 open/close cycles, including six in-air and three TVAC deployments (Ref. 5).


Figure 19: TacSat-4 UHF antenna design (image credit: NRL, Ref. 36)


Figure 20: Photo of the stowed TacSat-4 UHF antenna (image credit: NRL)


Figure 21: TacSat-4 mission highlights and CONOPS (image credit: NRL)


LHP (Loop Heat Pipe):

The challenges facing the COMMx payload TCS (Thermal Control System) were extensive. These challenges included heat dissipation of 600-700 W within a payload volume of approximately 1 m diameter by 1 m high, and the need to accommodate significant periods of payload off time [Ref. 34) and Ref. 5)].

The temperature limits of the electronics boxes are 0 to+40ºC during normal operations and -30ºC to +50ºC during survival mode. Variable spacecraft orientation meant that the radiator view could change from deep space to full sun during payload operations.

At the beginning of the program, a trade study of various thermal control technologies and architectures was conducted. The result showed that only a CTB (Central Thermal Bus) concept and LHP (Loop Heat Pipe) technology in conjunction with a LHP temperature control method met the TCS requirements.

The CTB architecture for spacecraft TCS was first proposed by the Naval Center for Space Technology at the NRL in 1994. The essence of the CTB approach is to package all heat dissipating devices in close proximity at a central location inside the spacecraft while using a cooling technology to: (i) collected the waste heat, (ii) transport it to the spacecraft radiators, and (iii) reject it to space at the location where heat removal is most efficient. The CTB offered many advantages over traditional TCS architectures. Among them are mass/volume savings, ease of integration of the payloads, and optimal placement of the electronics inside the spacecraft to enhance radiation shielding.

The TacSat-4 spacecraft uses an experimental aluminum/ammonia LHP (Loop Heat Pipe) of ACT (Advanced Cooling Technologies, Inc., Lancaster, PA) to transport ~ 700 W of heat from the electronics to two radiator sections. 37) 38)

A functional schematic of the LHP is shown in Figure 22. It consists of a capillary pump, condenser(s), a reservoir, vapor/liquid transport lines, and a Thermoelectric Cooler (TEC). The operating principle of a LHP can be summarized as follows: (i) heat from the source conducts through the capillary pump casing to vaporize liquid on the outer surface of the wick, (ii) the vapor travels along the vapor line to the condenser where it rejects the heat to revert back to liquid, and finally (iii) the liquid flows in the liquid line to the pump to complete the cycle. The LHP condenser is not utilized entirely for condensation. A portion of it cools the exiting liquid below the saturation temperature, allowing the system to overcome environmental heating and heat leaks from the evaporator. There always exists both liquid and vapor in the reservoir such that its temperature and pressure control the saturation condition of the entire loop.


Figure 22: Functional schematic of the LHP technique (image credit: NRL, ACT)

A functional LHP schematic of the COMMx CTB TCS consists of a one evaporator with two parallel condenser sections. The evaporator contains a high performance, sintered nickel primary wick with a robust, screen composite secondary wick (Figure 23). The power dissipating electronics boxes/modules are attached to a honeycomb panel that has two embedded CCHPs (Constant Conductance Heat Pipes). The LHP evaporator is attached to the CCHPs and transfers the heat from the CCHPs to one or both of the condensers, depending on the temperature of the radiators that are attached to the LHP condensers. Each of the two radiator sections consists of four segments of the octagonal shaped satellite envelope. The electronics boxes with the highest heat dissipation are mounted on both sides of the main deck, Figure 25.

The payload thermal system is one of the most advanced space systems flown, and uses a central thermal bus design with multiple heat pipes (Ref. 28).


Figure 23: Schematic view of the TacSat-4 thermal control system (image credit: ACT, NRL)


Figure 24: The LHP pump-reservoir assembly of TacSat-4 (image credit: NRL)


Figure 25: TacSat-4 payload electronics enclosure configuration (image credit: NRL)


Figure 26: (a) COMMx thermal model with deployed UHF antenna; (b) COMMx thermal model with stowed UHF antenna (image credit: NRL)


TSSCE (TacSat Solar Cell Experiment):

TacSat-4 also carries a PV experiment of advanced III-V multi-junction cells in a variety of configurations including a concentrator, lightweight substrates and polymer coverglass substitutes. There are four samples being flown: 39)

• A 3 cell string of EMCORE BTJM cells thinned to 100 µm

• A 3 cell string of EMCORE ATJM (Advanced Triple-Junction with Monolithic Diode) concentrator cells under an ENTECH Stretched Lens supported by ATK structure and tensioning mechanisms

• A thinned (100 µm) EMCORE BTJM cell with POSS filled DC 93-500 silicone serving as a cover glass, mounted on ATK’s UltraFlex® gore material

• And a thinned (100 µm) EMCORE BTJM cell with a 150 µm thick CMG, AR coated coverglass bonded with DC 93-500 silicone and mounted on ATK’s UltraFlex® gore material.

The HEO orbit of TacSat-4 is providing a high radiation environment with an anticipated PV array degradation of 25% in one year for triple-junction III-V cells. As Figure 27 shows, the orbit will pass through the Proton Belt as well as the Electron Belt. This orbit will provide valuable insight into the radiation hardness of these new technologies.


Figure 27: Schematic view of the TacSat-4 HEO environment (image credit: NRL)

One of the design motivations for TSSCE was to satisfy the new standard AIAA S-122-2007, “Electrical Power Systems for Unmanned Spacecraft.” Spacecraft built using this standard will require monitoring 0.3% of the array solar cells. This experiment uses minimal spacecraft resources while providing high fidelity characterization of solar cell strings or individual cells. This circuitry is easily adaptable to measure strings up to 75 W.


CEASE (Compact Environmental Anomaly Sensor Experiment):

The CEASE dosimeter instrument, developed by ATC (Assurance Technology Corporation) and Amptek Inc. of Bedford, MA, is of DSP-21 (Defense Support Program-21, launch Aug. 6, 2001), TSX-5 (Tri-Service Experiments Mission 5, launch June 7, 2000), and STRV-1c (of DERA, launch Nov. 16, 2000) mission heritage. The objective of CEASE is to provide warning to satellites of space-environmental conditions likely to cause anomalous operations such as: surface charging, deep dielectric charging, single event upsets (SEU's), or radiation dose effects. The dosimeter collects data of electrons > 1.2 MeV and protons > 25 MeV. CEASE provides the opportunity to sample the high energy electron population fluxes in the HEO environment during electron events.

The instrument has a size of 10 cm x 10 cm x 8.2 cm, a mass of 1 kg, and power consumption of <1.5 W. An RS-422 or 1553B interface is used.


Figure 28: Photo of the CEASE-II instrument as flown on TacSat-4 (image credit: ATC and Amptek)



Ground system:

The spacecraft mission is being monitored and controlled at Navy's BPTF (Blossom Tracking Point Facility), Maryland. Additional coverage is being provided from AFSCN (Air Force Satellite Control Network). The payload tasking is on SIPRNET [Secure Internet Protocol Router Network (integral part of DoD's Defense Information Systems Network)] and VMOC (Virtual Mission Operation Center).

The VMOC development over the last five years has allowed the community to explore new concepts of operations supporting the standardization of spacecraft to ground interfaces needed to reduce costs, maximize space effects to the user, and allow the generation of new tactics, techniques and procedures that lead to responsive space employment. The three main thrusts were the US Air Force platform apportionment and command and control, US Army theater access to payloads, and the US Navy’s operational experimentation and the FORCEnet principles. Each thrust focused on a specific aspect of ORS (Operationally Responsive Space). OSD (Office of the Secretary of Defense) and ONR (Office of Naval Research) funded efforts and demonstrations in 2008 which led the ORS Office to select the VMOC as the primary ORS Payload Tasking and Asset Visibility capability for the ORS 2015 Ground System Enterprise. 40) 41) 42) 43)

TacSat-4 will provide the first opportunity for USSTRATCOM (U.S. Strategic Command) to apportion ORS assets. TacSat-4 will exercise VMOC in day-today operations. Daily operational use will mature apportionment, mission management and operational user scheduling capabilities. For TacSat-4 the VMOC will interface with NRL’s Blossom Point ground station and be used with Blossom Point’s highly automated, “lights out” mode of operations. An important aspect of the TacSat-4 VMOC is to be a pathfinder for the ORS-1 (Operationally Responsive Space-1) spacecraft, also referred to as ORS Sat-1 (launch June 30, 2011). VMOC servers are located at NRL to support Blossom Point operations of TacSat-4, and at Schriever Air Force Base, Colorado Springs, CO, to support SOC-11 operations of ORS-1. 44)

NRL has developed the common, open-architecture of VMOC, a web-enabled multi-application service, that ushers in a new era for globally-dispersed military users of DoD, commercial, and civilian satellite payloads. Specifically, VMOC is a highly automated planning and scheduling tool; it handles all of the tasking and channel allocations for the TacSat-4 mission. VMOC allows authorized satellite end users and operators the dynamic reallocation to different theaters worldwide that enables rapid SATCOM augmentation when unexpected operations or natural events occur. Operators can submit task requests, generate optimal schedules, and autonomously execute those tasks through satellite commands. The VMOC is not an experimental application, but an operational, accredited system, serving as the primary tasking tool for the U.S. DoD's ORS Office.

The BPTF is a certified SOC (Space Operations Center) on the AFSCN, and provides supporting on a daily basis as necessary to space missions. In addition, combined BPTC/VMOC operations tests were performed using a test bed developed for the mission that resides at NRL (Ref. 28).

Once the initial spacecraft checkout phase was completed, the BPTF transitioned to an automated process for most of the TacSat-4 command and control function.

All radio testing, including COTM, BFT, and Data-X, is conducted using the ITGT (In-Theater Ground Terminal).


VMOC (Virtual Mission Operations Center), an overview :

With notably few exceptions, space platform architectures are paired with mission specific ground infrastructures designed to optimize the interface. While these stovepipes can be efficient within themselves, they don’t allow for common user access, prioritization, multi-mission management, or cross-platform connectivity. Additionally, they are typically designed to maximize the number of utilities available for a highly-trained human operator to navigate through rather than emphasizing automation and speed. The result of this approach, consistent across all areas of military space operations, repeatedly leads to higher operational costs for three reasons: 45)

1) the lack of software code reuse between satellite operations and mission planning software

2) highly sophisticated systems require highly trained operators

3) the lack of automation means the cost to operate these systems is substantial, as manpower costs are significant. Additionally, these highly tunable, but seldom automated, systems are not scalable to be responsive to rapidly changing operational conditions.

To be more operationally responsive, and yet compatible with foreseeable budgetary constraints, the U.S. DOD , through their Research & Development communities, are increasingly interested in developing highly automated, satellite ground systems, built around a common core, that can be used across a spectrum of space force enhancement missions. The NRL (Naval Research Center) has decades of heritage in doing this for national security space systems with its CGA (Common Ground Architecture). With the help of mission partners from the ONR (Office of Naval Research), the ORS (Operationally Responsive Space) Office, as well as industry partners, the NRL has developed and deployed a common, open-architecture, web-based application called VMOC (Virtual Mission Operations Center), that allows authorized satellite end users and operators to submit task requests, generate optimal schedules, and autonomously execute those tasks through satellite commands.

The VMOC is not an experimental application, but an operational, accredited system, serving as the primary tasking tool for the ORS Office. It is space-qualified and in use today in support of the ORS-1 mission, supporting USCENTCOM (US Central Command) as well as the TacSat-4 satellite, providing worldwide UHF SATCOM. The VMOC was designed so that any, or all, of its suite of capabilities can be rapidly implemented with minimal impact to existing ground infrastructures, greatly improving responsiveness, providing shared situational awareness, and serving as a single, collaborative environment for all participants in the planning, scheduling, operating, and approval process. Additional capabilities and tools can be employed as familiarization and operational concepts evolve.

From its initial conception, the VMOC was designed to achieve two primary objectives:

• To improve the speed of command (or the mission planning process) by leveraging automation tools to the maximum extent possible

• To be as ubiquitous and flexible as possible in its ability to quickly add new missions and capabilities through the use of open standards and shared applications.

The VMOC has succeeded on both accounts and is supporting worldwide users on a daily basis, providing imagery and SATCOM tasking capability and status directly to those who will be exploiting those resources, while still facilitating the critical functions of operational control and real-time status updates from ground controllers. Typically, the timelines for servicing satellite payload resource requests, which is routing electronic forms within the multi-tiered approval process, takes on the order of 30 days to request, approve, apportion, schedule, and execute. Today (2012), with the VMOC available as a shared resource among all these stakeholders, the process is being done on a 24 hour timeline, with full capability to generate short-turnaround schedules in minutes.

Individual applications within the VMOC are closely linked to ensure shared awareness. The VMOC, as a web-based application, breaks down the barriers to entry for potential users, requiring two things, 1) user access to the network (i.e. SIPRNet), and 2) Administrative privileges. Then, without the need to add firmware or plugins, all that is needed is a username and password.

There are dozens of mission planning and tasking tools that simply provide static information between the user and the host server. VMOC’s power comes in the fact that the information and schedules generated are transferred, machine-to-machine, to the executor of those missions. A good example is the interface between VMOC and the BPTF, which serves as the TacSat-4 Spacecraft Operations Center (SOC). VMOC uses a pre-defined set of meta-language scripts, negotiated by an ICD (Interface Control Document), to automatically translate the user schedules into spacecraft commands. They are interleaved with the health and status commands generated by the SOC to produce a single uplink command file. This is unprecedented in today’s military SATCOM construct.

With the VMOC, a single deployed user who requests UHF SATCOM services on TacSat-4, can generate a satellite service request and obtain services without another human interaction before obtaining those services. In so doing, VMOC ensures that the space vehicle and payload can support the unique requirements of the user without violating performance limits of the spacecraft while simultaneously meeting the priorities, or quality of service, of the operational commander responsible for the utilization of that SATCOM mission. The entire planning cycle is limited only by the desires of the operational commander, for VMOC can generate schedules virtually instantly. The time-to-execute is limited only the by capability of the SOC to generate satellite uploads and scheduling an uplink opportunity, which VMOC factors in, a priori, because the SOC operators are able to input the uplink schedules into VMOC.

The VMOC performs the function of task planner, collector, and scheduler, as well as interface with the ground segment executor of the mission. The other core capability it has includes the ability to reach out to other web services to gain or update information critical to planning or scheduling functions. In the case of the ORS-1 mission it complies with standard APIs (Application Programming Interfaces) to autonomously gather data from the AFWC (Air Force Weather Center) to determine cloud cover as part of its optimization algorithm. Another successful API is used between VMOC and a theater-planning database called PRISM (Planning Tool for Resource Integration, Synchronization, and Management). This machine-to-machine interface allows the theater to request tasking of the ORS asset using the same tool used for air breathing ISR (Intelligence, Surveillance and Reconnaissance) platforms, with the added advantage of providing automated feedback on the status of requests. Notwithstanding the AFWC and PRISM interfaces, VMOC has only just begun to leverage the tremendous potential of these network enabled machine-to-machine interfaces.

The various Satellite Support Centers manage the time “allotments” and prioritizations of TacSat-4, which the VMOC uses to assist the end user in planning as well as generating optimized schedules. During the entire process, all users are kept updated on the status of their individual requests, much like tracking a FEDEX package. Nominally, schedules are promoted every 24 hours, but can accommodate rapid “time sensitive” requests, as required. The final schedule is then automatically transferred to the SOC (Satellite Operations Center) where the satellite and payload commands are automatically generated and uplinked to the spacecraft.

Figure 29 shows the three major applications used in VMOC, which have their functions closely tied to traditional phases of mission planning. They are the:

1) Tactical Application

2) Operational Planning Tools

3) Mission Application.

A fourth application is planned in the future is “Operational Assessment” that will greatly improve the ability of mission operators to quickly determine how well the task requests serviced by the VMOC are being met by satellite payloads managed by the VMOC.


Figure 29: The VMOC applications vs. Mission Planning functions (image credit: NRL)

Tactical Application:

The end-user requests, traditionally called SSRs (Space Support Requests) or SARs (Satellite Access Requests), are accommodated in the VMOC’s “Tactical Application”. The overall objective in designing this application was to make it intuitive for a user to request a satellite service without having to know anything about orbital mechanics or mission/payload constraints. It requires the end user of the satellite service to define the minimum amount of information needed to manage that request. But it is also flexible enough to allow an experienced user to refine characteristics of the request that may enhance the service.

The VMOC uses an AGI (Analytical Graphics Inc.) orbital services engine to provide the user predictive opportunities. The user need not worry about selecting a particular opportunity as the automatic scheduler will try to meet the task request at the first possible opportunity consistent with user and operational commander needs. However, the user has the option to manually select an opportunity if the situation dictates. The user may even set up a recurring task if the nature of the support is repetitive.

The Tactical Application is also used for all levels of users to check on the status of the tasks they have submitted or approved. This is essentially how the VMOC acts like a FEDEX tracking system. In fact, the user need not be logged into the VMOC to get status updates, as the VMOC notification feature will automatically send an e-mail to the user informing them of a change in task status. In other words, the Tactical Application gives situational awareness on the status of an individual task at every stage of the approval process.

The Tactical Application is even capable of handling machine-to-machine interfaces for task requests. The ORS-1 mission requires the VMOC to pull tasks from a collection management server where local users store and prioritize targets for multiple types of sensor collects. A very basic interface using standard protocols was created that allows the ORS-1 VMOC to pull tasks daily from the PRISM server. This capability greatly reduces manpower requirements that would otherwise be required to manually duplicate overhead imagery requirements in separate systems.

Operational Planning Tools:

These tools are designed for the mission managers, or those ultimately responsible for the employment and utilization of the satellite, to use to ensure that the VMOC schedule accurately reflects the priorities of the operational commander to whom the resource is assigned. They may choose to use any number of combinations of tools to achieve this. As the VMOC grows to support more missions, more tools will become available to future users.

One tool, called “Chain of Command Approval”, allows the Operational Commander to set up a tiered approval process for all user tasks. This tool requires active management of tasks prior to releasing them to the VMOC scheduler (the standard mode for task management is that all tasks automatically get sent to the scheduler unless deleted by an authorized approval (known as passive management). This ensures that tasks have a record account of all approval transactions prior to scheduling.

Another tool is called “Allotments”, which allows Operational Planners to assign predetermined timeslots in the future for a particular organization to optimize. This may be useful if an organization may otherwise be preempted by tasks from other organizations that have a higher priority. These “underserved users”, who might not otherwise be guaranteed satellite access, can utilize the timeslots to meet their needs. Unused accesses within these timeslots would then be pooled back into the general scheduling algorithm for adjudication.

“Priority Adjustments” is a very useful tool for resource allocators. It allows them to reflect the priorities of the mission commander across a wide set of parameters. For instance, if a particular AOR (Area of Responsibility) becomes a crisis area, then planners can quickly add a rule within the VMOC to assess a priority bump across all tasks within that AOR.

Mission Application:

This application is primarily used to ensure that the day-to-day changes made in satellite operations are reflected in the VMOC. Satellite TT&C (Telemetry, Tracking, and Command) schedules must be updated as well as payload downlink times. This is performed through the “Contact Manager” tool. Satellite operators can also schedule outages that the scheduler will automatically accommodate. Automatic notifications will get sent to alert users that a change has occurred in the ground segment configuration.


Automation where it counts:

So, what allows the VMOC to safely and efficiently perform its mission planning function autonomously? There are many variables that must be accounted for before a satellite resource can be scheduled and configured for a global set of users. Spacecraft subsystem constraints cannot be violated so as to put the spacecraft in danger. Or more specifically, the VMOC cannot allow the satellite to rely on its automatic fault protection to safe the spacecraft. In the case of ORS-1 and TacSat-4, both missions that use relatively small buses and form factors, those subsystem constraints are mission limiting, meaning that payload resources can cause subsystem safety limits to be reached. Accordingly, thermal, attitude control, and power models are used within the VMOC to ensure that schedules are not generated that could cause a local violation to occur. This feature requires careful planning during the requirements phase to determine the appropriate fidelity of the model. In the case of ORS-1, it was determined that the same attitude control model used by flight software was required to be used in the VMOC. The slewing acceleration limitations of the ORS-1 satellite demanded exact replication in the VMOC to ensure thermal violations would not occur, as well as ensuring that a sufficient algorithm could be devised to create target areas within the VMOC that could optimize the collection of high priority targets while minimizing the latencies inherent in slewing the vehicle.

Clearly, the processing power available with smart algorithms allows resource allocation to be optimized according to mission requirements. One lesson that was quickly learned as the VMOC was applied to a wider set of missions, it that optimization is relative. A utilitarian view of optimization would suggest that the VMOC automatic scheduler should simply schedule a weighted average of all tasks for a given period. However, that seldom translates into meeting Operational Commander requirements. If servicing the ten highest priority targets is assessed to be critical, then the VMOC schedule will optimize for that condition. If simply getting an average number of targets is the priority, the VMOC will optimize for that condition. Furthermore, as has been the VMOC’s experience, those optimization priorities may shift. The VMOC is designed so that new strategies for optimization can be employed without having to necessarily re-code. Many of the variables for optimization are “tunable” within a fixed array of variables. And those variables are made available to the responsible mission controllers.

Most importantly, the VMOC allows enough flexibility to allow for a full spectrum of automation: from full automation to complete manual scheduling. The ability for users to take full manual control of the scheduling process is important in some cases. There are always scenarios that cannot be predicted that make it an imperative for some missions to take temporary control of the scheduling process.


Mission Integration into the VMOC:

The VMOC was designed to be cost effective in adding new missions through the design of sharable resources. Figure 30 shows how the VMOC builds on a core set of applications common across all missions. Between the TacSat-4 and ORS-1 missions, the VMOC was able to re-use about two-thirds of its software code. That is remarkable in view of the fact that the two missions are distinctly different (COMSAT vs. Earth Sensing). It is estimated that code reuse will soon approach 95%. Of course, complete code reuse can never be achieved as all missions will have some unique components.


Figure 30: The VMOC architecture (image credit: NRL)

In the case of TacSat-4 (Figure 31), the VMOC enables the end user, for instance a forward deployed military UHF phone operator or network of operators, to input their SATCOM requests directly into VMOC via the Tactical Application. Nominally, this takes 1-2 minutes. All user requests are assimilated and evaluated by VMOC based on priority settings (defined in the Tactical Application), priority adjustments (defined in Operational Planning Tools) and layers of models. Some unique models for TacSat-4, not discussed earlier, include the automated calculation of link budgets based on payload and user equipment characteristics.


Figure 31: Illustration of VMOC operations for TacSat-4 (image credit: NRL)

In the case of ORS-1 (Figure 32), the VMOC daily pulls from a list of targets located on a PRISM server. In this case, all Operational Planning Tools are simply turned off due to the fact that tasks are operationally prioritized within PRISM itself. Through the use of extensive tunable parameters, accessible to specially-trained VMOC users, a locally defined optimization algorithm is generated and automatically executed.


Figure 32: Illustration of VMOC operations for ORS-1 (image credit: NRL)

VMOC’s path to space operations has followed a multi-year process that began as a simple request to make space capabilities more accessible to users and evolved into proving a mechanism to collaboratively manage disparate space and ground systems consistent with increasingly dynamic and responsive operations. In support of the responsive space goals, the VMOC has served as a forcing function to bring intelligence, operational, and science agencies together to refine and implement operational relationships and roles that are required for rapid tasking processes.

With the successful launches of ORS-1 in June 2011 and TacSat-4 in September 2011, VMOC, now space-qualified, has fully demonstrated the power of web-based planning, as it continues to enable a new era of rapid planning and improved space responsiveness. It is now clear that the VMOC approach to worldwide tasking is not only feasible, but also practical.

Between 2004 and 2008, the VMOC (Virtual Mission Operations Center) was developed through a series of operational demonstrations designed to support the standardization of spacecraft to ground interfaces needed to reduce costs, maximize space effects to the user, and allow the generation of new TTP (Tactics, Techniques and Procedures) needed to shape responsive space employment.

In 2008, VMOC development goals were refined to provide direct support to the TacSat-4 and ORS-1 missions. The launch of ORS-1 in June 2011 and TacSat-4 in September 2011 have now provided operations experience and lessons learned. These operations activities continue to serve as a forcing function for refining TTPs and concepts of operations.

The organizations that have been most involved in the VMOC development and testing include NASA, Air Force Battlelab, Army SMDC Battle Lab, ONR (Office of Naval Research), ORS (Operationally Responsive Space) Office, Blossom Point operations, MMSOC (Multi Mission Space Operations Center) operations, JSpOC (Joint Space Operations Center), and NRL (Naval Research Lab) as the program manager for VMOC.

Operational VMOC support to the ORS-1 imaging and TacSat-4 SATCOM missions has shown that it can reduce manpower and time requirements for scheduling satellite payloads during daily operations from hours to minutes. In the case of ORS-1, VMOC was designed and developed to support a single user though a single input interface.

Table 3: Some background on VMOC 46)

1) C. Ford, M. Johnson, K. Weldy, R. Baldauff, T. Duffey, M. Gallelli, “TacSat-4 Design & Lessons Learned to Date,” Proceedings of the 4S Symposium: Small Satellite Systems and Services, Chia Laguna Sardinia, Italy, Sept. 25-29, 2006, (ESA SP-625, November 2006)

2) T. Doyne, R. Riddle, M. Johnson, M. Hurley, P. Wegner, K. Weldy, “A TacSat and ORS Update, Including TacSat-4,” AIAA 4th Responsive Space Conference, April 24-27, 2006 Los Angeles, CA, USA

3) T. Doyne, P. Wegner, C. Olmedo, G. Moretti, M. Hurley, M. Johnson, T. Duffey, C. Huffine, “ORS and TacSat Activities Including the Emerging ORS Enterprise,”AIAA 5th Responsive Space Conference, April 23-26, 2007, Los Angeles, CA, USA, RS5-2007-4001

4) TacSat-4 Overview, AIAA 5th Responsive Space Conference, April 23-26, 2007, Los Angeles, CA, USA, URL:

5) Bill Raynor, Mike Hurley, Tim Duffey, Mark Johnson, Ken Weldy, Ed Becker, Chris Amend, Mike Nurnberger, Bob Skalitzky, Trevor Specht, Eric Bradley, Bob Baldauff, Jesse Armiger, Jim Barnds, Keith Akins, Joel Hicks, Eric Sydow, Gurpartap Sandhoo, Doug Bentz, Brian Davis, Erik Gruner, Ken Whedbee, “TacSat-4, Advanced UHF SATCOM,” Proceedings of the Symposium on Small Satellite Systems and Services (4S), Funchal, Madeira, Portugal, May 31-June 4, 2010

6) Tom Doyne, Peter Wegner, Randy Riddle, Mike Hurley, Mark Johnson, Ken Weldy, “A TacSat and ORS Update Including TacSat-4,” 4th Responsive Space Conference, Los Angeles, CA, USA, April 24-27, 2006, paper: RS4-2006-4006, URL:

7) Patrick A. Stadter, Cheryl L. B. Reed, Eric J. Finnegan, “Effectively Integrating Laboratory, Government, and Industry to Develop and Acquire National Security Space Systems,” Johns Hopkins APL Technical Digest, Vol. 29, No. 3, 2010, pp. 234-246, URL:

8) Gurpartap S. Sandhoo, Aaron Q. Rogers, Patrick. A. Stadter, Eric Finnegan, Michael Hurley, Mark Johnson, William Raynor, Paul. D. Schwartz, James Griswold, “Standards for Responsive Small Satellites,” Proceedings of the IAA Symposium on Small Satellite Systems and Services (4S), Rhodes, Greece, May 26-30, 2008, ESA SP-660, August 2008

9) Jason Wilkenfeld, “Operationally Responsive Space: Transforming the Space Enterprise,” 13th ISU (international Space University) Annual International Symposium, Feb. 18-20, 2009, Strasbourg, France

10) P. A. Stadter, M. T. Marley, C. T. Apland, R. E. Lee, B. D. Williams, E. D. Schaefer, P. D. Schwartz, R. Denissen, B. Kantsiper, E. J. Finnegan, W. Raynor, G. S. Sandhoo, M. Johnson, J. Griswold, “Responsive Spacecraft Bus Implementation for HEO Missions Designed to Bridge Prototype and Operational Systems,” 6th Responsive Space Conference, AIAA-RS6-2008-4003, April 28–May 1, 2008, Los Angeles, CA, URL:

11) P. A. Stadter, C. S. Schein, M. T. Marley, C. T. Apland, R. E. Lee, B. L. Kantsiper, B. D. Williams, E. D. Schaefer, S. R. Vernon, P. D. Schwartz, E. J. Finnegan, J. C. Garner, G. S. Sandhoo, W. Raynor, T. A. Doyne, “Responsive Spacecraft Bus Implementation for Unique HEO Missions Based on Standard Interfaces,” AIAA 5th Responsive Space Conference, April 23-26, 2007, Los Angeles, CA, USA, RS5-2007-4004

12) G. S. Sandhoo, M. Johnson, W. Raynor, M. Hurley, P. A. Stadter, M. T. Marley, C. T. Apland, R. E. Lee, J. R. Bruzzi, B. D. Williams, E. D. Schaefer, S. R. Vernon, P. D. Schwartz, G. Moretti, T. A. Doyne, “ISET ORS Bus Standards and Prototype,” Proceedings of the 21st Annual Conference on Small Satellite, Logan, Utah, USA, Aug. 13-16, 2007, SSC07-I-2

13) P. Jaffe, T. Specht, G. S. Sandhoo, M. Johnson, W. Raynor, M. Hurley, P.. A. Stadter, P. D. Schwartz, B. Davis, J. Griswold, “TacSat- 4 Prototype Bus & ORS Phase III Bus Standards Update,” Proceedings of the 22nd Annual Conference on Small Satellite, Logan, Utah, USA, Aug. 11-14, 2008, SSC08-I-2

14) G. Kellams, C. Leonard, “Small Satellite Producibility, Affordability Approaches and TacSat 4 Design for Manufacturing and Assembly Results,” Proceedings of the 22nd Annual AIAA/USU Conference on Small Satellites, Logan, UT, USA, Aug. 11-14, 2008, SSC08-I-6

15) G. S. Sandhoo, T. W. Lim, P. G. DeLaHunt, W. C. Raynor, M. Johnson, M. Hurley, W. F. Dellinger, P. A. Stadter, J. Griswold, “ADCS Implementation of Operationally Responsive Space Bus Standards for a HEO Communication Mission,” Proceedings of the 7th International ESA Conference on Guidance, Navigation & Control Systems (GNC 2008), June 2-5, 2008, Tralee, County Kerry, Ireland

16) Brian Davis, “Interface Standards as an Enabler for Operational Responsive Space,” GSAW 2008 (Ground System Architecture Workshop), March 31 - April 3, 2008, Redondo Beach, CA, USA

17) W.C. Raynor, T. J. Specht, W. R. Braun, E. A. Rossland, S. N. LaCava, M. S. Johnson, P. A. Stadter, C. T. Apland, J. R. Bruzzi, M. T. Marley, B. D. Williams, R. A. Denissen, D.C. Bentz, “Integration and Testing Challenges of the Operationally Responsive Space (ORS) Phase III Bus Standards Prototype,” Space Research and Satellite Technology, 2009, NRL Review, URL:

18) Paul Jaffe, Greg Clifford, Jeff Summers, “SpaceWire for Operationally Responsive Space (ORS) as Part of TacSat-4,” International SpaceWire Conference 2007, Dundee, UK, Sept. 17-19, 2007, URL:

19) Brian Davis, “Interface Standards as an Enabler for Operationally Responsive Space with an Overview of NRL’s Flight SW Base,” Nov. 13-14, 2008, URL:

20) “Orbital Minotaur IV launches with TacSat-4,” NASA, Sept. 27, 2011, URL:

21) Rachel Berstein, “TacSat-4 Launched by Minotaur 4 Rocket,” Space News, Sept. 27, 2011, URL:

22) P. Jaffe, G. Clifford, J. Summers, “SpaceWire for Operationally Responsive Space as part of TacSat-4,” First International SpaceWire Conference, Dundee, UK, Sept. 17-19, 2007, URL:

23) D. Schierlmann, P. Jaffe, “SpaceWire Cabling in an Operationally Responsive Space Environment,” First International SpaceWire Conference, Dundee, UK, Sept. 17-19, 2007, URL:

24) Derek Schierlmann, Eric Rossland, Paul Jaffe, “Lessons learned from implementing non standard SpaceWire cabling for TacSat-4,” Proceedings of the International SpaceWire Conference 2008, Nov. 4-6, 2008, Nara, Japan, URL: and the URL of the presentation:

25) “TacSat-4 spacecraft complete and awaiting launch,” Dec. 3, 2009, URL:

26) Matthew Anderson, Bill Raynor, Mike Hurley, “TacSat-4: Military Utility in a Small Communication Satellite,” Proceedings of the 27th AIAA/USU Conference, Small Satellite Constellations, Logan, Utah, USA, Aug. 10-15, 2013, paper: SSC-X-7, URL:

27) Mike Hurley, Matt Anderson, “TacSat-4: Military Utility in a Small Communication Satellite,” Proceedings of the 9th IAA Symposium on Small Satellites for Earth Observation, Berlin, Germany, April 8-12, 2013, URL:,d.Yms&cad=rja

28) Tim Duffey, Mike Hurley, Bill Raynor, Ken Weldy, Eric Bradley, Trevor Specht, Chris Amend, Eric Rossland, Jim Barnds, Keith Akins, Steve Rauen, Bob Skalitzky, Steve Koss, Susie LaCava, Bob Baldauff, Doug Bentz, Jeff Johnson, Jonathan Bruzzi, Fred Hellrich, Matt Anderson, “TacSat-4 Integration, Testing, Launch Processing and Early Flight Operations Experience,” Proceedings of the 4S (Small Satellites Systems and Services) Symposium, Portoroz, Slovenia, June 4-8, 2012

29) Tim Duffey, Mike Hurley, Bill Raynor, Trevor Specht, Ken Weldy, Eric Bradley, Chris Amend, Eric Rossland, Jim Barnds, Keith Akins, Steve Rauen, Bob Skalitzky, Steve Koss, Susie LaCava, Bob Baldauff, Doug Bentz, Jeff Johnson, Fred Hellrich, Matt Anderson, “TacSat-4 Early Flight Operations Including Lessons from Integration, Test, and Launch Processing,” Proceedings of the 26th Annual AIAA/USU Conference on Small Satellites, Logan, Utah, USA, August 13-16, 2012, paper: SSC12-II-3

30) “TacSat-4 enables polar region SatCom experiment,” NRL News Release, March 9, 2012, URL:

31) “TacSat-4 Mission Tests New Spacecraft 'Bus' Standards,”JHU/APL, Nov. 21, 2011, URL:

32) “Low-cost UHF antenna deployed on Navy satellite,” Spaceflight Now, October 8, 2011, URL:

33) Ken Weldy, Amy Hurley, Chris Amend, Ed Becker, Mike Nurnberger, Keith Akins, Carl Ford, Mark Johnson, William Raynor, Mike Hurley, “TacSat-4 Mission and the Implementation of Bus Standards,” Proceedings of the 22nd Annual AIAA/USU Conference on Small Satellites, Logan, UT, USA, Aug. 11-14, 2008, SSC08-III-2

34) Robert W. Baldauff, W. Jesse Armiger, Triem T. Hoang, “Design and Analysis of the Thermal Control System for the TacSat-4 Spacecraft COMMx Payload,” NRL Review, 2009, URL:

35) Michael Hurley, William Raynor, Kenneth Weldy, “TacSat-4 COMMx, Advanced SATCOM Experiment,” 2009, URL:

36) Chris Amend, Michael Nurnberger, Paul Oppenheimer, Steve Koss, Bill Purdy, “A Novel Approach for a Low-Cost Deployable Antenna,” Proceedings of the 40th Aerospace Mechanisms Symposium, NASA Kennedy Space Center, May 12-14, 2010, NASA/CP-2010-216272, URL:

37) Peter M. Dussinger, David B. Sarraf, William G. Anderson, “Loop Heat Pipe for TacSat-4,” Space, Propulsion and Energy Sciences International Forum (SPESIF 2009), Huntsville, AL, USA, Feb. 24-26, 2009, Vol. 1103, pp. 91-100

38) “ ACT’s Loop Heat Pipe Achieves Highest Technology Readiness Level with Launch of TacSat-4 Satellite,” ACT, Nov. 7, 2011, URL:

39) Phillip Jenkins, Robert Walters, Scott Messenger, Michael Krasowski, “US Naval Research Laboratory's current Space Photovoltaic Experiments,” Proceedings of the 8th European Space Power Conference, Constance, Germany, Sept. 14-19, 2008, ESA SP-661, Sept. 2008

40) Eric Miller, Omar Medina, Mike Hurley, James C. Barlow, Ricardo J. Espindola, Ed Quinonez, Deborah James, “Virtual Mission Operations Center and ORS Ground System Enterprise,” 7th Responsive Space Conference, April 27–30, 2009, Los Angeles, CA, paper: AIAA-RS7-2009-6001, URL:

41) Eric Miller, “Virtual Mission Operations Center and ORS Ground System Enterprise,” 7th Responsive Space Conference, April 27–30, 2009, Los Angeles, CA, presentation, URL:

42) Omar Medina, Christine W. Balisle, Kimberly A. Holloman, Eric Miller, “Virtual Mission Operations Center: Transforming the conduct of space based operations,” 14th ICCRTS (International Command and Control Research and Technology Symposium), 'C2 and Agility', Washington, D.C., June 15-17, 2009, URL:

43) Eric Miller, Mike Hurley, Omar Medina, Jay Hopkins, Richard Lane, Ramon Veglio, Allen Kirkham, Will Ivancic, Brenda Jones, Ron Risty, “Virtual Mission Operations
Center (VMOC) Development and Experimentation,” 5th Responsive Space Conference, April 23–26, 2007, Los Angeles, CA, paper: AIAA-RS5 2007-6001

44) “NRL Ready to Deploy Virtual Mission Operations Center,” NRL News Release 95-10r, Aug. 31, 2010, URL:

45) Joel Hicks, Eric Sydow, Eric Miller, Larry Dikeman, Sandi Mohler, Mike Hurley, Thom Davis, Fred Hellrich, “VMOC Automated Mission Planning Now in Operations,” Proceedings of the 4S (Small Satellites Systems and Services) Symposium, Portoroz, Slovenia, June 4-8, 2012

46) Eric Miller, Joel Hicks, Mike Hurley, Matthew Anderson, James Barlow, Kim Holloman, Ed Quinonez, “VMOC and Responsive Space Ground System Operations,” Reinventing Space Conference, May 7-10, 2012, Los Angeles, CA, USA, paper: AIAA-RS-2012-6002, URL:

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.

Minimize Related Missions

The TacSat series: