You are here

Hosted Payload Support Technologies


OBJECTIVE: Develop technologies to support the effective use of hosted payloads on military and/or commercial satellite systems for DoD applications. DESCRIPTION: There is an increased interest in the so-called"hosted payload", which refers to the ability to add a secondary payload(s) opportunistically to a spacecraft having an otherwise specific, dedicated primary purpose. Hosted payloads are being explored on commercial, military, and civil spacecraft platforms. A DoD-sponsored hosted payload was recently demonstrated by DoD in the Commercially Hosted Infrared Payload (CHIRP) mission as a viable method of deploying a payload at a fraction of the cost (10-25%) of the cost of developing a dedicated mission to field the same payload. It is intuitive that cost savings can accrue when the bulk of the infrastructure of spacecraft, launch, and sometimes ground operations and communications burden can be borne by a primary user. As such, the hosted payload concept is attractive both to the payload developers as well as the prospective sponsors, who can use the revenue generated by a secondary payload to defray expenses in the overall development of a primary mission. While it is not likely the hosted payload will service every mission concept, it could be very attractive for a majority of potential mission candidates. The notion of a"hosted payload"is in a sense not a new idea. The idea of multiple payloads on a single satellite is almost as old as the"artificial satellite"itself. Over the years, secondary and tertiary payloads have been added to spacecraft missions. More recently, ideas such as the space plug-and-play architecture (SPA), the Self Awareness Space Situational Awareness (SASSA) and (in Europe), Space Avionics Open Interface Architecture (SAVIOR) have all been introduced as concepts for standard interfaces, and some of these may have applicability. However, any prospective standard for hosted payloads must meet a number of key requirements: (1) open interface specifications for power, mechanical, thermal, and informatics; (2) the need to support high-bandwidth (e.g.>100 Mbits/sec); (3) the ability to accommodate high-power payloads (>100W), (4) the need for sophisticated command/control/telemetric support for a rich, diversity of prospective payload types; and (5) the ability to support strong encryption / multi-level security protocols. This latter requirement is a special challenge to hosted payloads, since commercial spacecraft represent at the same time an abundant opportunity for fielding missions and a concern for the comingling of critical payload data and unknown varieties of primary bus command, control, and information products. None of the contemporary concepts (e.g. SPA, SASSA, and SAVIOR) have to this point sufficiently addressed these requirements. An indirect (but equally important) challenge in creating a hosted payload concept to implement a solution that adds very little size, weight, and power (SWAP) overhead to the primary, ideally less than 2 per cent of dry mass and end of life power consumption of the host. Other auxiliary concerns relating to commodization of the hosted payload is (1) the lack of tools dedicated to managing a database of known hosted payload opportunities and surveying/analyzing the suitability of candidates to the purposes of particular user applications and (2) toolkits for easily integrating the mission products of hosted payloads into typical ground system infrastructures. Addressing these barriers will likely save cost (estimates range from 50-90%). The standardization is likely to improve mission assurance by regulating the form and format of the payload power, data, command, and mechanical interface, reducing uncertainty and simplifying the integration process (the effort of connecting a hosted payload to available hosts). Presumably, the standardization would take hold on both sides of the"problem", the host and the payload. Addressing the second barrier would promote a widespread use of the hosted payload concept in future missions and spur increased availability by prospective hosted payload offerors. PHASE I: Provide solutions that demonstrably meet the stated requirements for hosted payloads. Standard interface/analysis tools are examples. The interface addresses power/electrical interface/synchronization with a data protocol to be concise/flexible for variable payloads. Tools involving computer-aided design/modeling/simulation/analysis with consideration of enterprise resource planning must explore. PHASE II: Offerors must provide convincing progress towards a transitionable solution based on the ideas explored in the Phase 1 activity. Partnerships with others and identification of additional sponsorship is encouraged. PHASE III: Military Applications: As demonstrated in the CHIRP mission, hosted payloads make sense for DoD. Commercial Applications: Through standardization, the concepts addressed in this topic are equally useful to commercial payloads and commercial sponsors providing hosted payloads as a"service". REFERENCES: 1."CHIRP- Commercially Hosted Infrared Payload", webpage at the"Hosted Payloads"community site, sponsored by Space News (, accessed 1 November 2011). 2. McGuinness, Deborah; Wright, Jon,"An IndustriaI-Strength Description Logic-Based Configurator Platform", IEEE Intelligent Systems, Vol. 13, No. 4, July/August 1998, pp. 69-77. 3. Charett, Robert."Open-Source Warfare".IEEE Spectrum.
US Flag An Official Website of the United States Government