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)

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

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)

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.

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.

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.

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.

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.

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

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. 27).

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)

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.

• 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.25)

- 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 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. 25).

• The TacSat-4 spacecraft and its payload are operating nominally in 2013. 26) 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. 27)28)

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. 27).

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. 27).

• 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. 29)

• 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. 27).

• 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. 31)

Experiment complement: (COMMx, LHP, TSCE, 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. 32)33)34)

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:

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

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 ±150o 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.

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. 35)

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.

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

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. 33) and Ref. 5)].

The temperature limits of the electronics boxes are 0 to+40oC during normal operations and -30oC to +50oC 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.

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.

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. 27).

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: 38)

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.

One of the design motivations for TSCE 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.

Experiment description: The spacecraft has two solar arrays, oriented along the +Y and –Y directions. These solar arrays track the sun in two axes with an accuracy of ±5°. The –Y wing has a 3-cell string of Emcore BTJM (Triple-Junction with Monolithic Diode) cells on Ge substrates thinned to 100 µm, with 150 µm CMG cover glass, mounted directly to the solar array honeycomb substrate. There is also a single BTJM cell, with a POSS® coverglass replacement, attached to an open weave fabric known as Vectran, mounted to a frame. A photograph of the –Y wing test objects is shown in Figure 28. 39)

The +Y wing has a 3-cell string of EMCORE ATJM cells with 508 micrometer coverglass mounted under a single-element molded linear Fresnel lens made of DC 93-500, providing 6.34 X concentration. The lens is protected from UV darkening by a UV rejection coating. A single BTJM cell with a 150 micrometer CMG cover glass mounted in a similar fashion as the BTJM cell with the POSS® cover glass replacement on the –Y wing, serves as a control cell for the POSS® cover. A photograph of the +Y wing test objects is shown in Figure 29.

The TacSat-4 bus provides switched 28V power and four A/D channels to the TSCE electronics. When the TSCE is energized, the electronics cyclically bias the solar cell string though its I-V curve using an electronic load and alternately measure the two single cells at short circuit current (Isc). Each biasing cycle lasts one second. The electronics condition the current and voltage signals to conform to signal ranges of the A/D channels provided by the TacSat-4 bus. The bus then samples the A/D channels at an effective rate of 150 Hz for ten seconds.

Figure 30 shows typical I-V curves for the two solar cell strings. Data collection occurs when operations permit. During the first three months of spacecraft operation the experiment was only operated occasionally. Once the spacecraft had completed the checkout phase, data sets were collected daily.

Operations and Observed Artifacts: The TacSat-4 orbit is highly elliptical and endures thermal cycles that vary significantly with altitude and eclipse period. At perigee, the solar array temperature was observed as high as 70°C. At apogee the temperature was typically 50°C. As the TSCE was a secondary payload, data collection times were scheduled not to interfere with primary operations, thus the I-V curves were collected at various altitudes.

Figure 31 shows an example of the variation in open circuit voltage (Voc) of the BTJM string with altitude. In the interval shown, and using the BTJM temperature coefficient for Voc of 6.5 mV/°C per cell, the implied temperature difference of an I-V curve collected at 900 km vs. 8800 km is 7°C. Most of the data collection over the two years occurred at altitudes above 8000 km where the temperature is relative stable, between 50°-55°C. But there are several periods where I-V curves collected at lower altitudes are apparent in the data.

The solar cell current is a much weaker function of temperature than cell voltage, but temperature and albedo illumination effects can be seen in the current data. Figure 32 illustrates the artifacts to Isc due to a confluence of factors; high solar beta angle, and low altitude. When the solar cells are facing the sun under these conditions, the cells have a substantial view of the earth, creating a significant rise in solar cell current from earth albedo. On mission day 178, the data acquisition altitude drops from > 4000 km to ~900 km and a slight increase in current is seen at this transition due to increased temperature at lower altitudes. But as the beta angle rises from +46° on Day 225, to over +86° on Day 253, the solar cells see more and more of the illuminated earth creating a nearly 4% increase in current on Day 253. As the data acquisition altitude increases though, starting on Day 254, the albedo illumination contribution decreases in spite of the +80° beta angle. So for a significant albedo contribution to the current, both low altitude and high beta angle are required.

Figure 32: The effects of low altitude and high solar beta angle on the solar cell current (image credit: NRL, EMCORE)

Results for the BTJM fl at plate string: The solar cell data presented are shown along with predictions using the AP/E-8 and AP/E-9 radiation models as well as predictions modeled using particle fluence measurements from the on-board radiation spectrometer, CEASE.

The graph in Figure 33 plots Isc normalized to the beginning of life (BOL) value as a function of time in orbit for the BTJM string of cells labelled as black squares. These data are compared to radiation damage simulations using the SCREAM code with the electron and proton environments of AP/E-8 and AP/E-9. The AP-8 case uses the AP8MIN environment and the AP-9 cases were run in Monte Carlo mode (100 simulations) and are represented by the mean case and the 95th percentile worst case. The solar cell degradation based on the radiation environment as measured by CEASE is also shown in Figure 33 and is better matched to the BTJM data. CEASE spectra were only available through the first 500 days of the mission at the time of this writing. Beyond day 500, the CEASE results are extrapolated from the last measurement set. This is indicated in the Figure by lighter color shades of the lines representing the modeled solar cell response. It is notable that both radiation models, AP/E-8 and AP/E-9 significantly under predict the damage. It should also be noted that these degradation calculations only consider degradation to the solar cell itself due to displacement damage, and not any darkening effects of the coverglass and/or coverglass adhesive. These would be additive to any loss seen in the degradation to the solar cell.

Figure 33: Remaining Isc of the BTJM cells compared to predictions using AP-8 and AP-9 radiation models as well as predictions using the measured data from the CEASE instrument (image credit: NRL, EMCORE)

The same type of plot in Figure 33 is shown for the BTJM Voc in Figure 34. Again, except for the artifacts due to temperature discussed above, the measured BTJM data agrees very well with the modeling results using the on-orbit CEASE radiation spectra.

Results for the Stretched Lens Array: Analysis of the stretched lens array is more complex than that of the BTJM string due to the 6X linear Fresnel lens. As previously reported, the lens began to suffered a mechanical failure approximately six months into the mission. During the first 6 months before any lens failure, the Stretched Lens Array suffered about 13% power loss, compared to about 30% power loss for the one-sun cells, as expected due to the thicker cover glass. Thereafter, the three cells illuminated by the lens suffered increasingly different illumination levels as the lens began to mechanically fail under the combined effects of thermal and mechanical stresses along with radiation embrittlement of the weak silicone lens material. Newer, more robust lens designs mitigate the observed mechanical failures. The focus is more on the results after the complete lens failure in the 14th month of the mission.

The lens failed completely, on 21 November 2012 (Mission Day 421). At which point, it is essentially a flat-plate ATJM string under a 508 µm coverglass, directly comparable to the BTJM fl at plate string with 150 µm coverglass.

The remaining power vs. time on orbit is shown for the stretched lens array (SLA) with and without the lens in Figure 35. The remaining BOL power fraction was determined either with the concentrator lens or without (using the one-sun value). Here to, modeling results comparing CEASE and AP/E-8 and AP/E-9 models are presented.

The modeled vs. measured data show the same trend as the BTJM cell, with the CEASE spectra matching the data more effectively. What is striking though is the level of protection offered by the thicker coverglass. At the two-year mark for the BTJM string with the thinner coverglass, the remaining power was only 60% of the BOL value, while the ATJM cell with a much thicker, 508 µm coverglass retained 88% of BOL performance.

Figure 35: Remaining power fraction of the ATJM cells compared to predictions using AP-8 and AP-9 radiation models as well as predictions using the measured data from the CEASE instrument (image credit: NRL, EMCORE)

Results for the POSS® Replacement Cover Glass: Two BTJM cells, each measured at short circuit, had one cell with a 150 µm CMG coverglass and the other with a POSS® coverglass replacement. The thickness of the POSS® cover was chosen to give the equivalent radiation shielding as the 150 micrometer CMG coverglass.

In Figure 36, a plot of the ratio between the shorted BTJM cell with 150 µm CMG coverglass compared to the BTJM cell with POSS® cover. This gives a measure in the relative transmission between the two coverglass materials. The POSS® suffered a 67% loss in current compared to the cell with CMG coverglass after two years. At the time this material was chosen for the experiment its radiation hardness was not well understood. Since then ground testing of POSS® material show it to be radiation soft. This experiment thus confirms ground test results.

Figure 36: Ration of Isc of the Cell with POSS® cover compared to the control cell with a 150 µm CMG cover glass (image credit: NRL, EMCORE)

In summary, the TSCE measured I-V curves of solar cells in flatplate and concentrator geometries experiment showed that the solar cell degradation rate was much higher than what is predicted by current radiation models. The CEASE radiation spectral data dramatically illustrated that the failing was not with the radiation response of the solar cells but rather with the accuracy of the radiation model predictions. The TSCE also demonstrated the utility of using thick coverglass in a high radiation environment, which allowed the solar cells to retain 88% of the BOL power compared to 60% of the BOL power when using thinner coverglass (Ref. 39).

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. 41)42)43)44)

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. 45)

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. 27).

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: 46)

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

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

In the case of TacSat-4 (Figure 41), 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.

In the case of ORS-1 (Figure 42), 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.

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.

26) 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

The information compiled and edited in this article was provided byHerbert 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 (herb.kramer@gmx.net).