Commercially hosted government payloads: Lessons from recent programs

In a commercially hosted operational mode, a scientific instrument or operational device is attached to a spacecraft but operates independently from the spacecraft's primary mission. Despite the expected benefits of this arrangement, there are few examples of hosted payload programs actually being executed by government organizations. The lack of hosted payload programs is largely driven by programmatic challenges, both real and perceived, rather than by technical challenges. Partly for these reasons, NASA has not sponsored a hosted payload program, in spite of the benefits and visible community interest in doing so. In the interest of increasing the use of hosted payloads across the space community, this paper seeks to alleviate concerns about hosted payloads by identifying these programmatic challenges and presenting ways in which they can be avoided or mitigated.


INTRODUCTION
In 1966, NASA's ATS-1 communication satellite carried meteorological sensors unrelated to its primary payload into space. The idea of using excess capacity on satellites to carry additional payloads has been considered since the inception of the industry. Due to their inherent cost and schedule benefits, commercially hosted payloads represent a significant opportunity for NASA and other government entities to fly science payloads and technology demonstration missions on orbit.
While not a new concept, hosted payloads have yet to be utilized by NASA or utilized extensively by the United States Government (USG). The limited use to date is due to both the perceived risks and the programmatic challenges associated with this new method of launching payloads. This paper summarizes a study of recent hosted payload programs with the intent to address the perception of risk associated with hosted payloads. It is intended that this study will provide the factual basis to increase access to space for suitable payloads using commercial hosting.

Definitions
In the context of this document, the term hosted payload refers specifically to a government payload that is launched to orbit as a secondary payload on a commercial host spacecraft. The host spacecraft provides resources to the payload such as structure, pointing, power, and communications. For the purposes of this paper, a hosted payload is not a second spacecraft on a shared launch; it is not a small satellite; it is not a suborbital payload; and it is not a secondary payload hosted on a government spacecraft. The hosted payloads can be technology demonstrations, research equipment, flight qualification units, or fully operational sensors or systems.
When referenced in this document, the customer is the government organization that is contracting to find a host spacecraft to take their payload or capability to orbit. The satellite owner is the commercial entity that owns the host spacecraft on orbit. Generally, the owner is also the same entity as the satellite operator, who is responsible for onorbit and ground operations throughout the satellite's lifetime. The spacecraft provider is the contractor that is responsible for manufacturing the satellite bus and the primary commercial payloads. The payload provider is the contractor that is responsible for developing and building the hosted payload itself. In some cases, the spacecraft and payload providers are the same contractor. The system integrator is responsible for integrating the hosted payload and spacecraft and is often the same as either the spacecraft provider or the payload provider. In some cases the system integrator is also responsible for subcontracting the hosting opportunity.

Motivation
The primary goal of the study that led to this paper is to examine the experiences of government agencies with hosted payloads and to identify the lessons learned. This goal is addressed through the identification of successful approaches for implementing hosted payloads on commercial communications satellites. The hosted payload option is not viable for all NASA payloads, but it is appropriate for meeting a select subset of USG needs. Additional goals include satisfying the 2010 National Space Policy and create new opportunities to meet the desire for low-cost science missions to Geostationary Earth Orbit (GEO) that would not be feasible under current mechanisms and funding. It should be noted that hosted payloads can also be hosted on commercial spacecraft in Low Earth Orbit (LEO). The commercial satellite market in GEO is larger than the commercial LEO market and affords more frequent opportunities for hosting.
Cost Overruns and Schedule Growth-USG space programs often experience significant cost and schedule overruns. Four examples of cost overruns, shown in Figure 1, are the Advanced Extremely High Frequency (AEHF) program, the National Polar-orbiting Operational Environmental Satellite System (NPOESS), Space Based Infrared System (SBIRS), and Global Positioning System (GPS). As can be seen in Figure 1, NPOESS has doubled in cost since its inception and SBIRS costs are nearly three times the original estimate.
Program schedules grow similarly, resulting in capabilities arriving on orbit many years beyond their target date. The capabilities are therefore often out of date by the time they become operational.
Additionally, any replacement capability is often delayed, requiring the on-orbit capability to remain operational long past its expected lifetime.
Hosted payloads provide an innovative solution to cost and schedule overruns. The hosted payload program schedule is inherently constrained to the schedule of the satellite owner, as will be discussed in more detail later. The constrained schedule does not allow for delays in the development of the hosted payload, in order for the payload to be integrated and tested in time for the launch. Since the schedule cannot generally be adjusted, there can be little allowance for creep in the payload capabilities/requirements. The limit on requirements creep helps reduce the potential for cost overruns.

Figure 1: Program Cost Growth From Initial Estimate[1] Image used with permission from SMC/XR
2010 National Space Policy-The 2010 National Space Policy, released on June 28, 2010, drives USG towards the hosted payload option in two ways. First, it specifically directs that agencies "Work jointly to acquire space launch services and hosted payload arrangements that are reliable, responsive to United States Government needs, and costeffective." Additionally, the policy states that agencies should "Actively explore the use of inventive, nontraditional arrangements for acquiring commercial space goods and services to meet United States Government requirements, including measures such as…hosting government capabilities on commercial spacecraft." [2] Second, the National Space Policy includes several areas that can be addressed in part through a hosted payload program, including providing cost-effective assured access to space, "Develop and Retain Space Professionals" to support Science, Technology, Engineering, and Mathematics (STEM) initiatives, "Strengthen Interagency Partnerships," provide for "Potential International Cooperation," and "promote a robust domestic commercial space industry."[2] Each of these areas is addressed through the natural benefits of the hosted payload option, as will be discussed later. Commercial interest can also be seen in the participation of high level personnel (industry Vice Presidents, Directors, etc.) in the Inter-agency Hosted Payload Working Group. The working group is an ongoing set of working meetings led by the National Space Security Office (NSSO) to address the procurement, legal, and acquisition issues associated with hosted payloads. Many of the commercial operators have personnel specifically tasked to work on hosted payloads.

Interest in hosted payloads
Commercial owners are actively seeking new opportunities to host payloads, including remote sensing payloads. Research journals such as Science have recently carried advertisements for hosted payload services.

Benefits of Hosted Payloads
Financial Benefits-There are clear financial benefits from hosted payloads for both USG and the commercial companies involved. When procuring a new commercial satellite, the satellite owner invests a large amount of money up front to fund the build and launch of the spacecraft. Since they do not make any of this money back until the spacecraft is on orbit and operational, there is a strong incentive to keep the schedule short. Hosting a payload offers an opportunity for the owner to offset some of those initial costs by providing accommodation for a secondary payload on their spacecraft. There is an associated reduction in total spacecraft lifetime, because the payload mass offsets stationkeeping propellant. However, the small loss of revenue 10-15 years in the future is more than offset by the present value of the payments that are received for the hosted payload accommodations prior to launch.
For USG, the low-cost access to space is a primary benefit, compared to the cost of developing a dedicated spacecraft and paying for its launch. The payload development costs are the same in either case, but the government program will only pay a small fraction of the spacecraft development and launch costs for accommodation on the commercial host. The highly modular commercial spacecraft buses minimize non-recurring engineering costs.
The short schedule associated with hosted payloads, which constrains personnel costs to a few years, further reducing the cost to a USG hosted payload program.
Schedule Benefits-The reduced schedule of a hosted payload compared to a standard NASA spacecraft development is a benefit in and of itself. A hosted payload program could last roughly 3-4 years from concept to launch, compared to normal programs lasting 5-10 years or more. The short schedules allow more opportunities for hosting USG payloads than can be provided by large, multisensor satellite development programs.
Beyond the  An example of a commercial spacecraft development schedule is shown in Figure 2, lasting approximately 30 months from the spacecraft Request For Proposal (RFP) to launch. This schedule is much faster than typical USG development programs. In order to utilize this process, the USG customer should start coordinating with the satellite owner in the 18 months prior to the owner's RFP for a spacecraft. Successful coordination could enable the hosted payload accommodations to be included in the spacecraft RFP. Inclusion in the owner's RFP may make integration of the hosted payload fit more easily into the existing commercial processes. To meet the commercial schedule, it is preferred that the hosted payload be delivered for integration and test (I&T) 12 months before the planned launch date.
The 2010 National Space Policy-Many aspects of hosted payloads specifically address areas defined in the National Space Policy. For example, commercial spacecraft provide "Assured Access to Space" because of the steady and continuous launch of spacecraft to almost all regions of GEO. On average, commercial owners together launch over 20 GEO spacecraft per year, each of which is an opportunity for a hosted payload. These spacecraft operate at the locations shown in Figure 3 providing opportunities for payloads over the entire globe (except for a small region over the Pacific Ocean). It may be noted that many commercial companies keep a similar image indicating their spacecraft locations updated and available online. The specific dates associated with specific launch opportunities must be gathered by the customer or system integrator, as there is not currently a publicly-available central repository for upcoming launch information. The customer can ensure that the payload arrives at a useful orbital slot, if that is a mission constraint, by working with multiple spacecraft owners across the industry during the development of the mission concept. Although industry is interested in hosting USG payloads, it will only do so if the business case closes for the specific spacecraft being considered. This primary commercial mission may limit the payloads that can be hosted on a particular satellite.
The National Space Policy also seeks to "promote a robust domestic commercial space industry." Hosted payloads offer a direct way to strengthen the commercial industry. By offsetting the up-front investment by commercial owners, hosting allows the industry to operate with reduced risk. The arrangements also take advantage of existing capacity in the existing commercial infrastructure, which includes the spacecraft, launch vehicles, and ground systems. The inherent strength of the commercial satellite industry has enabled it to pass through the recent global recession with little impact. Beyond the commercial industry, hosted payloads also offer opportunities for interagency and international cooperation.
Supporting Science, Technology, Engineering, and Mathematics (STEM) Initiatives-Hosted payloads may appear attractive to students and young professionals in the aerospace industry and other STEM fields. The hosted payload schedule is relatively short and offers more opportunities for practical hands-on experience to train systems engineers, principal investigators, and program managers. Hosted payloads may also help retain a highly qualified workforce by providing opportunities to work on multiple missions over a decade, rather than a single project.

Challenges of Hosted Payloads
One of the largest challenges facing hosted payloads lies in aligning the way USG and commercial industry operate. This alignment includes agreeing to a schedule that satisfies the needs of all parties and, just as importantly, keeping to the agreed-upon schedule. There are also procurement and legal matters that must be addressed to allow easier use of hosted payloads as a means for USG and industry to work together.
Across the USG, some institutional resistance to using this new method of launching payloads exists. In part, this resistance is driven by the perceived risks associated with the non-standard way of contracting, procuring, and meeting standards for quality assurance and mission assurance.
As previously stated, the rapid commercial schedule provides some benefits to the USG customer. However, it represents a challenge for the customer to design and develop a payload, conduct the appropriate reviews, compete and contract for the hosting accommodations on a timetable that aligns with the commercial schedule. For instance, the NASA Announcement of Opportunity (AO) process can include multiple rounds of reviews and take over a year to select science missions to fund. Developing a hosted payload mission through this mechanism is challenging because the hosting opportunities must be identified far enough in advance to allow time for the review process, selection, payload development, integration, and testing prior to the desired host spacecraft's launch date. Planning and coordination between the customer and industry with different schedules will require some adjustments on both sides. Alternatively, a new method of contracting this type of mission may be desired, incorporating the lessons learned from past programs presented later in this paper.
Quality and mission assurance are also areas where the USG customer may need to alter its practices somewhat for a hosted payload program. The schedule of such a program may not allow time for the full set of development review cycles, which may require the customer to accept insight into the commercial quality assurance processes rather than normal level of oversight.
Commercial owners are generally risk averse and have a high level of quality assurance processes. It may be beneficial to treat the purchase of accommodations on the host spacecraft as a commercial purchase, rather than a development contract.
Recent hosted payload programs have generated lessons for potential issues and mitigations to address in the commercial contracts to avoid change orders and renegotiations later in the program.
Uncertainty in the payment process may arise from USG budgetary processes, including delayed appropriations and congressional continuing resolutions.

Study Objectives
As stated previously, the main goal of this study is to provide sufficient information to enable the use of commercially hosted payloads within NASA programs. This goal is addressed by identifying successful approaches for hosting payloads on commercial satellites and examining the perceived risk of commercial access to space. The study team investigated five recent instances of commercially hosted government payloads, with a focus on the programmatic and procurement aspects of the programs.
The investigation of these programs consisted of contacting the personnel involved to obtain information about how the programs were initiated and operated, how contracting and procurement issues were handled, what issues arose, and what lessons were learned during the program. In addition, the team also made contact with individuals at several satellite owner/operators and manufacturers to discuss potential approaches for future hosted payload programs.
The final goal of the study was to develop a cost estimation model based on actual commercial contracts. This model can be used to estimate costs and payment schedules for future hosted payload programs.

RECENT HOSTED PAYLOAD PROGRAMS
The five recent hosted payload programs chosen for study are:    Table 1 summarizes high level programmatic characteristics of these five programs, including the primary companies and government agencies involved, with the primary contractor highlighted in bold text. Table 2 displays basic information about the hosted payload itself for each of the programs. A notional NASA science payload would fit well within the ranges indicated in Table 2 for mass, power, volume, and data rate.
Each of these programs provides its own set of lessons regarding potential issues to mitigate and each program will be described in detail in the following sections.

WAAS: Wide Area Augmentation System
WAAS is a FAA program that uses two L-band payloads on two satellites to enhance the accuracy of GPS signals for improved aircraft navigation and safety. The portion of WAAS specifically associated with the hosted payloads is referred to as the Geostationary Communications and Control Segment (GCCS). Prior to the launch of the two hosted payloads in 2005, WAAS was operated through leased L-band payload services on existing commercial satellites. The current WAAS/GCCS system has been used to improve air traffic management and increase airport throughput since the launch of both host spacecraft in 2005. The GUSs and backup GUSs were part of the ground system developments associated with the GCCS contract.
The WAAS GCCS contract was awarded to Lockheed Martin, as illustrated in Figure 4. Lockheed Martin was responsible for building the two payloads and was also responsible for securing the host accommodations for those payloads. The contract included an option for a third spacecraft, but this was not exercised. The first host spacecraft is Galaxy 15, which is owned and operated by Intelsat, was built by Orbital Sciences, and was launched by ArianeSpace. Galaxy 15 was undergoing re-work for a new business case when Lockheed arranged for WAAS integration. The second host spacecraft is Anik F1R, which is owned and operated by Telesat, was built by EADS Astrium, and was launched by ILS. Lockheed had discussions with Telesat for several years, and WAAS payload requirements were included in their contract with EADS Astrium. The GCCS contract included 10 years of operation of the hosted payloads. The payloads are used operationally in support of aircraft navigation and the contract contains provisions to prevent the L-band hosted payloads from being shut off by the spacecraft.
FAA established informal peer to peer teaming arrangements in addition to the formal contract structure. The informal teaming was credited for part of the program's success.    Takeaway Lessons-FAA modified their contracts to Indefinite Delivery Indefinite Quantity (IDIQ) contracts for up to 3 WAAS payloads with hosting arrangements. These IDIQ contracts provided an additional flight opportunity without repeating the lengthy solicitation and contracting process.

AIS: Automatic Identification System Demonstration
The AIS hosted payload was a program sponsored by the USCG to demonstrate the concept of receiving and retransmitting AIS signals from orbit. This LEO demonstration mission was part of the larger Nationwide AIS (NAIS) system being developed by USCG for the Department of Homeland Security. NAIS allows the collection of AIS signals from ships up to 2000 nautical miles offshore for identification and tracking.

Figure 5: Primary Actors in the AIS Hosted Payload Program
The AIS hosted payload began with a Firm, Fixed-Price (FFP) contract awarded to ORBCOMM on May 20, 2004, for $7.8M. ORBCOMM was responsible for building the AIS payload, integrating it with the bus and primary payload, launching the Coast Guard Demonstration Spacecraft (CDS), and performing on orbit operations. As illustrated in Figure 5, ORBCOMM subcontracted the bus manufacturing, spacecraft integration, and launch to Orbitale Hochtechnologie Bremen -System (OHB-System, or OHB). OHB handled integration and testing of the payload and bus, but subcontracted to Polyot for the manufacturing of the bus and the launch operations. [7,8] ORBCOMM subcontracted with Orbital Sciences to build both the primary payload and the AIS payload. ORBCOMM operated the spacecraft and its payloads, and provided the downlinked AIS data to USCG. ORBCOMM was also able to market the AIS data to other buyers if they were approved by USCG.
[9] The AIS hosted payload was developed along with the primary payload in about one year, and it took three months to complete integration with the bus. [10] The AIS demonstration program experienced several delays. First, there were some technical issues associated with the primary payload that delayed the launch of the spacecraft. The delays caused by the loss of the intended launch vehicle were more significant. The CDS was intended to share this launch vehicle with a Russian spacecraft. However, the Russian Ministry of Defense objected to the USCG payload and the CDS was removed from that launch. [7,11] Subsequently, it took several years to find another launch.
In the end ORBCOMM launched the CDS along with five other AIS-equipped ORBCOMM spacecraft in June, 2008 on a Russian Cosmos launch vehicle.
The other five ORBCOMM spacecraft, referred to as Quick Launch spacecraft, also included AIS secondary payloads and were built in parallel with the CDS. The Quick Launch spacecraft were scheduled to launch a year or more after the CDS, but the launch delays led to all six spacecraft launching on a single vehicle. The combined launch represented a potential risk for ORBCOMM because the AIS concept had not yet been proven. However, the joint launch provided a strong start on marketing AIS data services. [7,11] Ultimately, this arrangement proved to be beneficial to ORBCOMM, because the CDS failed in August, 2009. The USCG had contracted for the capability to receive and transmit AIS data, and ORBCOMM was able to supply that capability using the Quick Launch spacecraft instead.
The hosted payload program was beneficial for ORBCOMM because it created a new market for the sale of AIS data services. USCG initiated the AIS data market and can now buy AIS data services commercially. The AIS data is provided through existing commercial infrastructure, so the USCG does not have to maintain or upgrade the space or ground systems associated with the AIS capability. [11] AIS payloads are now used internationally to monitor shipping. [8] AIS Payload-The AIS demonstration payload was a Very High Frequency (VHF) receiver/transmitter with a mass of about 3 kg and power requirement of about 8 W. Data was downlinked at a rate of 10 kbps and minimal commanding was required. The only modification required to the existing ORBCOMM bus design to accommodate the AIS payload was an extension of the antenna. [10] USCG provided performance specifications for the capability, but did not design or develop the payload. USCG attended regular design reviews, such as a Preliminary Design Review (PDR) and Critical Design Review (CDR), but their oversight was limited. [11] Contracting-The contract between USCG and ORBCOMM covered the payload design, build, integration, test, and launch along with on orbit checkout and one year of operations. This contract also included an optional oneyear extension for operations, which the USCG exercised. [11] ORBCOMM owned the CDS spacecraft and the AIS hosted payload, and USCG had no financial liability when the CDS bus failed. [11] The contract did not specifically cover termination liability. USCG was obligated to pay for all work up to a termination for convenience. The contract also did not cover insurance, but ORBCOMM insured themselves. [7,11] Since ORBCOMM was responsible for the primary and hosted payloads along with the bus, there were no issues specifically associated with the hosted payload damaging or delaying the primary payload or spacecraft, or vice versa. [11] Takeaway Lessons-Both the USCG and ORBCOMM benefited from the new market for AIS data services that was created through the hosted payload program. The contract was simplified by having a single, responsible prime contractor.
Restricting the operation period of the demonstration satellite to one year with a one year optional extension was later viewed as a limitation. It is recommended that for any potential extensions, options be built into the contract for each year of extension beyond the original baseline duration. [11] Issues with foreign governments are potential concerns for any hosted payload program due to the multinational composition of commercial satellite companies and launch service providers.

IRIS: Internet Router In Space
The IRIS hosted payload program is a DoD-funded program executed by a partnership between Intelsat and Cisco to provide Cisco routing capabilities on orbit. IRIS allows routing to be performed on an operational spacecraft rather than bringing the data stream to the ground to perform the routing function. The IRIS payload is hosted by Intelsat 14, which was launched in November 2009. [12,13] The Intelsat/Cisco team developed the payload in response to a RFP for space-based Internet routing capabilities published by the United States Strategic Command as a Joint Capability Technology Demonstration (JCTD) project. The proposal award was for $12.1M, but Cisco also contributed internal research and development funding to the effort. The award covered development of the payload and the first 90 days of operations. Further operational time up to the 10-year expected lifetime of the payload is to be paid from user fees.

Figure 6: Primary Actors in the IRIS Program
The contract with DoD was awarded in April 2007. The IRIS payload was delivered to the commercial host for integration 6 to 7 months before the planned launch in the first quarter of 2009. The team subcontracted with ViaSat for the software defined radio (SDR) portion of IRIS and with SEAKR for packaging the payload electronics. The Intelsat commercial host spacecraft was a Loral 1300 bus, manufactured by Space Systems/Loral. The relationships between the various actors are illustrated in Figure 6. After the successful launch and 90-day checkout on orbit, the operator is now soliciting users for the payload as regular commercial customers.

IRIS Payload-
The IRIS payload is a Cisco Internet router that has been packaged for space. In place of the normal baseband local area network connection, the IRIS payload interacts with the user via a SDR that can support an aggregate data throughput of 60 Mbps to users separated by intercontinental distances. The payload has a volume of 0.127 m 3 , a mass of 90kg, and uses 250 W of power. The control of the payload from the ground is accomplished via background command and telemetry links, much as is done with the router in its ground configuration.
Contracting-Cisco is not normally a builder of spacequalified electronics and they elected to use subcontractors for the execution of the space hardware. ViaSat provided the SDR based on their commercial line. SEAKR provided the integrated payload package.
Takeaway Lessons-Despite having no prior experience with space electronics, Cisco found that their commercial development and test processes were competitive with others in the aerospace industry. As such, they did not need to modify their processes to develop a space-capable version of their existing router. [12] A useful step undertaken by the IRIS team was to develop a mass model of the payload. The mass model served to reduce risk since it could be flown instead if the IRIS payload was unable to meet the delivery schedule, without requiring any adjustments to the rest of the commercial mission. [12]

CHIRP: Commercially Hosted Infrared Payload
The CHIRP flight demonstration program is a risk reduction measure for the USAF Third Generation Infrared Surveillance (3GIRS) system. The hosted payload is an on orbit test of the capability of a wide field-of-view (WFOV) IR staring sensor from GEO, which will increase the Technology Readiness Level of this type of sensor. [14] In December, 2005, the USAF received new direction for its space-based infrared system, which was tasked to SMC. SMC developed requirements for a next-generation missile warning system and selected WFOV sensors as the most promising technology. SMC then tasked the Air Force Research Laboratory (AFRL) to develop this technology, through competitive processes.
Several companies developed sensor designs, including SAIC, whose design consisted of four ¼-Earth staring sensors. [1] In January, 2008, the government received an unsolicited proposal from AGS for a "Commercially Hosted Infrared Payload." The proposed hosted payload program would host one of SAIC's ¼-Earth sensors with the remaining capacity on the nadir deck of an existing communications spacecraft, which AGS had scheduled for launch to GEO in 2010. By June, 2008, a FFP, sole source contract had been awarded to AGS for $65M to complete the CHIRP technology demonstration as outlined in the AGS proposal. Figure 7 illustrates the contractor relationships and lines of communication of the CHIRP program. A simpler structure would be more desirable, but the unsolicited proposal from AGS could not be modified without re-competing it. AGS's parent company, SES, had an existing order with Orbital Sciences for three spacecraft (OS1, OS2, and OS3). [14] AGS was to manage the program and provide one year of operations for CHIRP. AGS contracted Orbital Sciences to modify the OS2 spacecraft with a Secondary Payload Interface (SPI) to accommodate the hosted payload. Orbital Sciences was also responsible for developing the CHIRP Mission Operations Center. Orbital Sciences subcontracted the payload, integration, and CHIRP Mission Analysis Center developments to SAIC. [15] However, in order to protect proprietary information and avoid any contract issues, the SAIC team responsible for the CHIRP payload was internally firewalled from the SAIC team that had been developing the ¼-Earth ground sensors under the existing contract with AFRL. Communications between AFRL and AGS were limited to the status of the payload and payload tests. Additionally, communications between AGS, OSC, and SAIC were limited to a single contact person at each organization. The situation created a limited flow of information between all parties, including to SMC. The restricted information flow created issues for the CHIRP program.

Figure 7: Primary Actors in the CHIRP Program
The original CHIRP schedule had a launch window from May to September, 2010. The delivery of the final CHIRP sensor was over a year late. This delay led to further delays as SMC and AGS renegotiated the future of the CHIRP program. [15,16] In the end, AGS switched the launches of OS2 and OS3 to accommodate the delays and enable the program to continue (at additional cost to SMC). The CHIRP payload was delivered to Orbital Sciences during the summer of 2010, with the launch currently planned for the third quarter of 2011. [16] CHIRP Payload-The CHIRP payload is similar in mass and complexity to the types of sensors that NASA might fly for science missions, making the program particularly interesting for the purposes of this study. The payload mass of 115 kg offsets about three years of stationkeeping propellant from the spacecraft. The revenue for those three years is accounted for in the contract cost. [1,15] The payload has a power requirement of 275 W, a maximum downlink capability of 70 Mbps, and a commanding rate of 5 Mbps. [16,17] CHIRP also includes two cryocoolers and a radiation shield to handle the high temperature environment of the nadir deck. At the beginning of the CHIRP program, the sensor existed as a ground based sensor that required some modifications for spaceflight. The required modifications included adding the radiation shield as well as a baffle cover. The cover serves as contamination control to protect the sensor from the outgassing of the rest of the spacecraft during the initial checkout period. [15,17] The payload is connected to the bus by the SPI, a system which encrypts the sensor data before it is passed to the spacecraft bus for downlink. This system ensures that no unencrypted data ever exists on the commercial spacecraft. [15,16] The SPI is a National Security Agencyapproved encryption device.
The encrypted data is downlinked through a leased commercial transponder. SMC also paid for additional transponders to be turned off, to offset power required for the CHIRP payload. These transponders may be activated and used for commercial services after the CHIRP program has been successfully completed. AGS asserts that on a larger bus, power would not be an issue and that they could have redesigned the power system with more time in the planning stages. [16] As a hosted payload, CHIRP is under a constraint to do no harm to the primary payload or the host spacecraft. This paradigm led to some modifications that were undesirable from SMC's perspective. These modifications include a fused power system that will permanently cut off the CHIRP payload if it draws too much power. The payload baffle was cut to support the communication satellite's omni antenna view, resulting in a slightly larger solar exclusion angle for the IR sensor. The baffle cutting was a result of the limited flow of engineering data from SAIC and Orbital Sciences. The lack of engineering data also led to a late change in the physical mounting of CHIRP to the nadir deck. Originally the payload was to mount directly to the deck, but was modified to include mounting legs. The legs contributed to issues during vibration testing.
The USAF program managers were involved in development, integration, and testing, but only for observation. AGS did the quality assurance, providing the USAF with insight, but not oversight. [16] Contracting-Contract payments were agreed to be 80% scheduled commercial payments and 20% incentive payments for successful completion of certain milestones. The CHIRP payment schedule was set up so that if SMC canceled the program at any time, AGS would always have been paid for all work completed. [18] The contract covers termination for convenience with limits on the associated costs. [1] The CHIRP contract includes a "shared risk" clause. This clause means that USG and AGS shared the risk for missing the original launch window. Specifically, the clause states that the CHIRP launch is at "no fault" to the contractor team or government.
The clause limits the financial responsibility of both parties and this clarity is important for avoiding lengthy renegotiations and getting the program back on track after a delay. [1] A limitation of the shared risk clause was that it did not cover what would happen in the event of additional delays after the May-Sept launch window had already been missed. The CHIRP sensor was delivered late and USG took an off-ramp for a delayed launch, which led to an engineering change proposal and a period of renegotiation. [16] The CHIRP payload was provided as Government Furnished Equipment (GFE) and AGS was responsible for integrating it with the rest of the spacecraft. Therefore, AGS would not be paid damages if the CHIRP payload damaged the primary payload or the spacecraft. [15,19] AGS included additional insurance premiums in their proposal to account for this possibility. [16] CHIRP was awarded as a sole source contract, based primarily on the justification that AGS was the only commercial owner/operator launching to the desired location in the desired timeframe. [1] The CHIRP contract included a clause that in the event of a congressional continuing resolution, USG would make "best efforts" to obligate funds in accordance with the agreedupon payment schedule, including event-based payments.
Once current year funds were released, USG would obligate funds against any unfunded commercial obligations. [14] During the period of time between the unsolicited proposal and the contract award, the spacecraft's designated orbit location was changed from 79 West to 103 West. Since contract award, the orbit location has changed again, to 87 West. The CHIRP team elected to continue the program with the new location, rather than take the option to terminate the program. [1,16] Takeaway Lessons-It was suggested by those involved in the CHIRP program that hosted payloads should be developed, tested, and built before contracting to put them into orbit. [14,15] It was also suggested to have a single contractor who is responsible for building, integrating, launching, and operating the payload. [15] Upfront systems engineering is important to avoid later technical issues, which cause costly modifications and schedule delays. The contract should include spacecraft specifications/data/models as contract deliverables. [14] ADF UHF: Australian Defence Force UHF Payload The ADF UHF payload is presently under construction for a launch in mid 2012 with an expected lifetime of 15 years. The UHF payload will comprise a significant portion of the Intelsat-22 spacecraft. The payload design is based on an existing US DoD communications payload that the ADF currently uses as part of a sharing agreement. The ADF awarded the contract to Intelsat in April, 2009. As illustrated in Figure 8, Intelsat subcontracted with Boeing to provide both the spacecraft bus and the UHF hosted payload.
The UHF payload will provide military communications for the ADF and allied forces, but will be controlled by the ADF. The contract award was for $167M and includes the payload, launch, and costs for 15 years of operation. [20] UHF Payload-The UHF payload is about 20% of the total payload capacity of the Intelsat spacecraft. It has a volume of 8 m 3 , a mass of 450 kg, and a 2 kW power requirement. The actual payload is based on existing military communications capabilities built by Boeing for the US DoD.
Contracting-The ADF indicated that there were many contracting issues due to the differences between nominal defense procurement and a commercial procurement. The ADF stated that these were solved through detailed and pragmatic negotiations on both sides. The ADF retained a special contracting lawyer to work the specific contracting details that were outside the normal ADF procurement process. [20]

Figure 8: Primary Actors in ADF UHF payload program
The key contracting issues for the ADF UHF payload revolved around which party assumes which risks and when those risks come into play. Most of these issues were resolved through the use of insurance. For example, the insurance in the contract covers launch plus one year of services, beyond which the service fee ceases if the payload is shut down. Termination conditions were also negotiated into the contract and covered by insurance.
The contract allows some amount of negotiation of the specific orbital arc location, provided that the ADF mission needs are still met.
Takeaway Lessons-The ADF team identified several items that have contributed to the success of their hosted payload program to date, including:  Having a single contractor for both the spacecraft bus and the hosted payload developments  Having a well-understood payload design that has been operated in orbit before  Using insurance to cover performance issues and schedule delays

RESULTS AND DISCUSSION
Throughout the course of the hosted payload study, the team met with employees of satellite manufacturers, satellite owner/operators, and others involved in hosted payload programs.
These meetings occurred at conferences, working groups, and in some cases, site visits with the teams. Through these contacts, the study team was able to acquire copies of the contracts from the WAAS, AIS, and CHIRP hosted payload programs, although in some cases certain commercially sensitive data was withheld or redacted.

Lessons Learned
Contracting Structures-In most of the hosted payload programs studied, the contract was signed between the USG customer and a single contractor, who was responsible for all aspects of the contract. In many cases, this prime contractor was the spacecraft owner, although in the case of WAAS it was with the payload provider. For WAAS, Lockheed Martin treated each of the WAAS hosting accommodations as a contract with a single spacecraft owner for the spacecraft and launch. Contracting with the spacecraft owners has been the preferred method of setting up a hosted payload program. Having a single prime contract was identified as a key lesson from most of these past programs.
CHIRP is the exception to the relatively simple contract structures of the other programs. Its more complex program structure was due to both the nature of the unsolicited proposal from AGS and the existing contract and relationships between SMC, AFRL, and SAIC. The more complex contracting organization of the CHIRP program created several issues related to program management and communication of technical data, which ultimately resulted in program delays.
Contract Terms and Conditions-From recent hosted payload programs, several identified items may be addressed in the terms and conditions of a hosted payload contract. These items are described below and, when available, the methods used to handle that item in the existing contracts are discussed. Additional detail about these and other contract terms and conditions can be found in the Hosted Payload Guidebook developed by Futron Corporation as a parallel to this hosted payload study. [21] Familiarity with potential issues and how to negotiate them is key for any future hosted payload contracts.
The schedule for a hosted payload program is critical, so the contract should address what happens in the event of a launch delay, payload delay, or a missed launch. Methods of addressing these events varied across the different programs and include program off-ramps built into the contract, using insurance as mitigation, or assigning penalty payments. The CHIRP shared risk clause provided for no fault to either party, although it only covered delays from the original launch window. Contractually addressing a delay or missed launch avoids difficult and costly renegotiation periods and keeps the program moving forward.
A hosted payload contract should also include mitigations or responses to a failed launch, hosted payload failure, or host satellite failure. If the contractor is responsible for developing and integrating the payload they generally bear the responsibility for any failures. In the case of a GFE payload, the customer would generally be responsible if their payload were to damage the primary payload or spacecraft bus. Again, in some cases failures were dealt with using insurance, and in others there were penalties for various types of failures.
In the event that the satellite operator changes the spacecraft's orbit location either before or after launch, the customer requires an option to continue the program at the new location or terminate the program if the new location is unacceptable.
Contracts generally provided language covering various types of termination and the associated termination liability. In the case of CHIRP, the payment schedule was set up so that AGS was always paid up for their work on the program so there was no additional liability. Figure 9, it is clear that the hosted payload program schedules generally ranged from 2 to 4 years. For some programs, this short schedule was possible because the communications payload being hosted was not complex or was of a fairly standard design. In the case of the CHIRP sensor, the schedule was possible because the ground version of the sensor had already been under development for eighteen months before the hosting contract was awarded. To host a NASA sensor, a key lesson is that the payload development should be at a CDR-level prior to awarding a hosting contract.

Program Schedules and Delays-From
Many programs experience schedule delays, so it is no surprise that the hosted payload programs shown in Figure 9 display them as well. Most also included some combination of delay in payload development and delays in the launch. The AIS launch delay, as described previously, was significant and was an issue associated with a foreign government objection, and not a technical payload issue. The CHIRP sensor shows the longest development delay, despite the prior development of the ground sensor. This development delay is attributed more to the limited flow of data across the program than the complexity of the sensor or integration itself. The ADF hosted payload program is not included in this figure since it is still early in the program execution. From the information available about the prices of past programs, the study team attempted to develop parametric equations or response surfaces that could be used to estimate the prices of future hosted payload programs. The resulting parametric model may be viewed as a rough order of magnitude (ROM) estimate at best, since it is based on only a handful of data points, some of which were estimated by the study team. The actual cost data used to generate the model cannot be displayed here since it is sensitive to the commercial entities involved in the programs.
The original approach was to plot total program cost against a number of payload parameters, program parameters, and combinations of the two. The cost for only the hosting accommodation portion of the program was also plotted against the same sets of parameters. The hosting cost includes the cost for interface development and integration of the payload onto the spacecraft, as well as any fees to the owner or spacecraft provider. The hosting cost does not include costs associated with operations, data processing, ground system development, or development/modification of the hosted payload itself.
Most of the resulting curve fits or response surfaces did not indicate any useful trends. Ultimately, the model which made the most sense was the simple linear fit to the plot of hosting accommodation cost versus hosted payload mass, which is shown in Figure 10. Fees for on-orbit operation of the hosted payload and data transmission are not included in Figure 10. The model in Figure 10 indicates a minimum cost of $6.6M for a contractor to consider hosting a payload. A minimum cost for consideration of hosting was expected. However, since each payload varies according to the specific business case associated with the host spacecraft, it is not clear that the indicated value is the correct value of that minimum. The model also indicates that the payload hosting costs increase by about $0.175M per kilogram. The result is that the model estimates a cost of $15M to host a notional 50 kg payload. It is logical that mass would be a cost driver and power would not. Due to the degradation of power generation from beginning to end of life, the host satellites will always have some excess power available after launch for a hosted payload to use.
One limitation of this cost model is that it mixes hosted payloads that are, from a commercial perspective, familiar communications payloads with unfamiliar payloads such as Earth-observing sensors. The lack of familiarity generally requires more careful examination of interfaces between the payload and the host spacecraft and increases the costs of integration and test.
The model may oversimplify any unusual circumstances associated with specific payloads including high payload power requirements, challenging thermal requirements, or specific contract terms and conditions that drove the price.

Figure 11: Sample Hosted Payload Payment Profiles
With the limited data available, the team also developed an average cost profile from hosting contract award to launch. Figure 11 shows the resulting average of three payment profiles, which were each scaled to two year durations and plotted as a percentage of all payments up to launch. Again, actual payments and dates are sensitive and therefore not included in this paper. The average payment profile, shown as a dotted line, indicates an initial payment of ~25% up front, followed by a steady payment rate afterwards.

CONCLUSION
Hosted payload programs are likely to continue to be used to satisfy niche needs for USG customers. The lessons from past programs gathered in this paper should serve to inform future program planning. The cost model developed can provide ROM estimates for hosted payload accommodation prices to further aid in planning.
High-level recommendations for future programs include:  Develop complex payloads to a CDR level prior to contracting for hosting accommodations  Simplify the program organization and lines of communication as much as possible  Treat the contract as the procurement of a commercial service rather than a development task  Address typical project events in the initial contract negotiations to avoid costly contract changes/renegotiations later in the program The hosted payload projects that were studied did not generally see themselves as models of sustainable acquisition.
In most cases, the projects captured opportunities that were less than optimal, but allowed the projects to proceed.
NASA and other USG agencies are capable of executing certain types of missions using the commercially hosted payload approach with its shorter schedules and lower cost, without sacrificing the quality of the returned data.
Within the US Government, the FAA, USCG, USAF, and DoD have already completed or are currently executing commercially hosted payload programs. Beyond that, the US DoD, through NSSO, is taking the necessary steps to make commercially hosted payloads a more commonly employed solution for satisfying certain aspects of their missions. NASA and other USG organizations may expand the use of hosted payloads for achieving appropriate aspects of their missions