Search NASA⌕ Search

SEARCH · Search NASA

Results for “Space Flight Architecture”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 199 records · Page 11

Enabling New Operations Concepts for Lunar and Mars Exploration

The planning and scheduling of human space activities is an expensive and time-consuming task that seldom provides the crew with the control, flexibility, or insight that they need. During the past thirty years, scheduling software has seen only incremental improvements; however, software limitations continue to prevent even evolutionary improvements in the operations concept that is used for human space missions. Space missions are planned on the ground long before they are executed in space, and the crew has little input or influence on the schedule. In recent years the crew has been presented with a job jar of activities that they can do whenever they have time, but the contents of the jar is limited to tasks that do not use scarce shared resources and do not have external timing constraints. Consequently, the crew has no control over the schedule of the majority of their own tasks. As humans venture farther from earth for longer durations, it will become imperative that they have the ability to plan and schedule not only their own activities, but also the unattended activities of the systems, equipment, and robots on the journey with them. Significant software breakthroughs are required to enable the change in the operations concept. The crew does not have the time to build or modify the schedule by hand. They only need to issue a request to schedule a task and the system should automatically do the rest. Of course, the crew should not be required to build the complete schedule. Controllers on the ground should contribute the models and schedules where they have the better knowledge. The system must allow multiple simultaneous users, some on earth and some in space. The Mission Operations Laboratory at NASA's Marshall Space flight Center has been researching and prototyping a modeling schema, scheduling engine, and system architecture that can enable the needed paradigm shift - it can make the crew autonomous. This schema and engine can be the core of a planning and scheduling system that would enable multiple planners, some on the earth and some in space, to build one integrated timeline. Its modeling schema can capture all the task requirements; its scheduling engine can build the schedule automatically, and its architecture can allow those (on earth and in space) with the best knowledge of the tasks to schedule them. This paper describes the enabling technology and proposes an operations concept for astronauts autonomously scheduling their activities and the activities around them.

Jaap, John↗

Shift changes, updates, and the on-call architecture in space shuttle mission control

In domains such as nuclear power, industrial process control, and space shuttle mission control, there is increased interest in reducing personnel during nominal operations. An essential element in maintaining safe operations in high risk environments with this 'on-call' organizational architecture is to understand how to bring called-in practitioners up to speed quickly during escalating situations. Targeted field observations were conducted to investigate what it means to update a supervisory controller on the status of a continuous, anomaly-driven process in a complex, distributed environment. Sixteen shift changes, or handovers, at the NASA Johnson Space Center were observed during the STS-76 Space Shuttle mission. The findings from this observational study highlight the importance of prior knowledge in the updates and demonstrate how missing updates can leave flight controllers vulnerable to being unprepared. Implications for mitigating risk in the transition to 'on-call' architectures are discussed.

Non-NASA Center↗

Evolving the Reuse Process at the Flight Dynamics Division (FDD) Goddard Space Flight Center

This paper presents the interim results from the Software Engineering Laboratory's (SEL) Reuse Study. The team conducting this study has, over the past few months, been studying the Generalized Support Software (GSS) domain asset library and architecture, and the various processes associated with it. In particular, we have characterized the process used to configure GSS-based attitude ground support systems (AGSS) to support satellite missions at NASA's Goddard Space Flight Center. To do this, we built detailed models of the tasks involved, the people who perform these tasks, and the interdependencies and information flows among these people. These models were based on information gleaned from numerous interviews with people involved in this process at various levels. We also analyzed effort data in order to determine the cost savings in moving from actual development of AGSSs to support each mission (which was necessary before GSS was available) to configuring AGSS software from the domain asset library. While characterizing the GSS process, we became aware of several interesting factors which affect the successful continued use of GSS. Many of these issues fall under the subject of evolving technologies, which were not available at the inception of GSS, but are now. Some of these technologies could be incorporated into the GSS process, thus making the whole asset library more usable. Other technologies are being considered as an alternative to the GSS process altogether. In this paper, we outline some of issues we will be considering in our continued study of GSS and the impact of evolving technologies.

Condon, S.↗

22 N HPGP Thruster Life Testing

In the ever-changing paradigm of efficient and capable spacecraft design, scientific missions continue pushing the envelope enabling spacecraft subsystems to deliver effective solutions to meet challenging new mission/spacecraft needs. From an in-space storable liquid chemical propulsion perspective, monopropellant hydrazine has been, and continues to be, a dependable propellant with considerable flight heritage, a variety of engine thrust classes available from multiple vendors, with repeatable and reliable performance. Additionally, the space propulsion industry has learned to successfully handle hydrazine, its regulations, the safety protocols, the personnel protective equipment, and the unique training standards–all requisite for loading spacecraft propulsion systems with toxic hypergolic hydrazine. The question now arises as to “what is next for in-space chemical propulsion?” Further, with the evolution and concrete advancements in innovative in-space green propellant technologies, capable of providing realizable benefits to scientific missions, concern over the reliability and availability of this higher performing and safer to handle class of propellants is waning. As science missions move forward with the potential flight in fusion of High Performance Green Propulsion (HPGP), NASA and its industry partners are working to address any gaps in system reliability, performance, or unique operational considerations. Propellant technology that offers both higher performance and significant reduction in personnel hazards compared to hydrazine presents an attractive propulsion subsystem design opportunity. Increased propulsion subsystem performance can result in lower spacecraft launch mass, larger scientific payloads, or extended on-orbit lifetimes. Mission trades using green propulsion technologies have been documented on multiple NASA Goddard Space Flight Center (GSFC) mission classes, examining various parameters and requirements to support mission architectures in Low Earth Orbit (LEO), High Earth Orbit (HEO), geostationary, lunar, planetary, and Quasi-halo orbit around Sun-Earth Lagrange point (L2). The results of these trade studies show promising, attainable benefits. The perceived programmatic risk of flying a newer propulsion technology has, unfortunately, not outweighed the benefits to date. To take advantage of the improved performance and mitigate programmatic risk, HPGP engines must demonstrate life testing at higher propellant throughputs than have currently been demonstrated. In an effort to proactively address the challenges with technology infusion into a risk-averse community, NASA and the Swedish National Space Agency (SNSA) outlined a collaborative Implementing Arrangement (IA) for the respective agencies to pursue increased HPGP technology maturation. This initial IA effort began in 2013, fresh off the heels of the successful PRISMA HPGP technology demonstration mission. The IA targeted objective is to reduce risk to potential future HPGP missions and fully characterize the LMP-103S propellant and associated engine performance. Over the past eight years, HPGP has flown in propulsion systems on twenty-five(25) spacecraft from seven(7) different Launch Ranges around the globe and on seven (7) different Launch Vehicles. Six(6) of these launches involved multiple loading operations for multiple spacecraft. For U.S. Range operations, nine (9) HPGP systems have been processed at Vandenberg Space Force Base(VSFB):six(6) in 2017, and three (3) in 2018. Six (6) more have been processed at Cape Canaveral Air Force Station (CCAFS)in May 2020, with three (3) systems launched in June 2020 and the remaining three (3) system were left loaded and ready until their launch in August of 2020. Three (3) more systems have been processed at Wallops Flight Facility(WFF)and launched in June 2021. In addition, these propulsion subsystems employed heritage propulsion subsystem component such as valves, filters, and pressure transducers, and have further demonstrated nominal functionality in both diaphragm and Propellant Management Device (PDM) propellant tanks. Based on these successes, HPGP technology continues to be considered for NASA Science Mission Directorate missions at GSFC. The work presented herein represents many years of development and collaborative efforts to successfully align higher performance, low toxicity hydrazine alternatives into scientific missions. NASA GSFC Propulsion Engineering, in collaboration with Bradford ECAPS, has developed mission specific thruster design and testing requirements to establish GSFC’s desired test conditions and firing sequences.In2017, the first flight-like 22N HPGP thruster Engineering Qualification Model (EQM-1)was designed and built by Bradford ECAPS to prove out the thruster design, materials, build process, and test campaign with respect to NASA GSFC critical component and mission requirements. This test program was developed to comprehensively test the thruster, the technology, and ultimately increase the 22N HPGP Technology Readiness Level(TRL). EQM-1was tested to environmental qualification levels prior to hot fire performance testing to represent the relevant end-to-end environment (launch to on-orbit operation)with required margin. This thruster demonstrated steady-state and pulse mode operational capability with propellant thruster throughput up to~53kg.At this throughput level, the EQM-1 engine began to present off-nominal performance and the test campaign was halted to allow for non-destructive testing and identify the root cause for the an omalous performance. Capitalizing on the successful elements of the EQM-1 campaign, an upgraded 22N HPGP EQM-2 has been manufactured by Bradford ECAPS to meet the complete GSFC requirements. The EQM-2 thruster’s test campaign has further demonstrated the robustness of the HPGP propulsion technology and increased the Technology Readiness Level (TRL) by undergoing a full acceptance test program, then proceeding into qualification, including environmental testing (vibration and shock to qualification levels),as well as hot-fire life testing, operating at steady-state and pulse modes with increased propellant thruster throughput to~150kg. The HPGP thruster performance testing enables effective HPGP thruster readiness evaluation to meet NASA candidate mission requirements in the future.

High↗

Rapid Spacecraft Payload Development: In-Orbit Demonstration of Flight Software Reuse, Scalability, and Dependability

As space mission design trends towards shared, multi-mission platforms and high-performance onboard computing architectures, the number of spacecraft launched into operation is also steadily rising. Through ridesharing, spacecraft miniaturization, and other cost-reduction measures, the barriers to space are lowering, resulting in compounded growth in the amount of flight software being deployed. To meet the needs of both the growing quantity and evolving nature of spacecraft, flight software design must accordingly adapt to support more efficient development, solutions to computational resource-sharing, and software reusability. This paper focuses on a software payload demonstrating several core technologies that improve the state-of-the-art in these identified areas. Launched into low-earth orbit in January 2022, our software payload was conceived, designed, and delivered in a span of merely two months. It was developed on top of the NASA core Flight System (cFS) framework and the Distributed Spacecraft Autonomy (DSA) Comm cFS application, which translates cFS software bus messages across a Data Distribution Service (DDS) network. The flight software, packaged in Linux container images, was deployed as one of 18 flight applications managed through the Unibap SpaceCloud Framework. The applications were run on a Unibap iX5-102 radiation-tolerant payload computer, hosted on the D-Orbit SCV-004 spacecraft as part of an ESA-sponsored in-orbit technology test. Our payload, referred to as the DSA D-Orbit software, demonstrates the reusability of the DSA Comm app in a substantially different context and purpose as its original mission. Comm’s original design goal was to reliably distribute messages between spacecraft swarms of arbitrary size and dynamic network topology. However, we leverage this same functionality to introduce redundancy and opportunistic parallel data processing in the context of a representative onboard image processing workload. This adaptive mission architecture was enabled in part by the SpaceCloud Framework’s use of container virtualization as the payload integration interface. By using a base container image with common high-level language runtimes and libraries, we were able to rapidly design, develop, and validate our image processing application without many of the technological barriers common to flight software development. We present details the goals, approach, results, and lessons learned through this technology demonstration experiment and contextualize those observations against present and future challenges in spacecraft software development.

computer programming↗

Desert Research and Technology Studies Exposure of Lotus Coated Electrodynamic Shield Samples

The passive Lotus dust mitigation coating currently being developed at NASA's Goddard Space Flight Center (GSFC), was selected by the Habitation Demonstration Unit Deep Space Habitat (HDU-DSH) for participation in the 2011 Desert Research and Technology Studies (D-RaTS). Based on the unique surface architecture of the Lotus leaf, the nano-engineered Lotus coating seeks to replicate these structures on space flight and habitation surfaces. By decreasing both the surface energy and area for particle attachment, the Lotus coating greatly diminishes dust accumulation on surfaces. This is a problem that can be encountered on lunar, Martian, and asteroid missions. Two different application methods of this coating were tested in summer 2011 at the D-RaTS site: the wet chemistry applied version and combustion chemical vapor deposition (CCVD) applied version. These Lotus coatings, along with two common thermal control coatings, were combined with the active dust mitigation electrodynamic shield (EDS) technology developed at Kennedy Space Center (KSC). The EDS technology uses an electrified grid to remove dust particles from the surface of a Kapton (Trademark) substrate. The Lotus coating and thermal control coatings were applied to these Kapton (Trademark) substrates for testing. The combination of these two innovations was theorized to be an applicable countermeasure for addressing dust accumulation during long-duration human space exploration. This theory was tested and characterized prior to, during, and after D-RaTS exposure.

Margiotta, Danielle V.↗

Exploration Architecture Options - ECLSS, TCS, EVA Implications

Many options for exploration of space have been identified and evaluated since the Vision for Space Exploration (VSE) was announced in 2004. The Augustine Commission evaluated human space flight for the Obama administration then the Human Exploration Framework Teams (HEFT and HEFT2) evaluated potential exploration missions and the infrastructure and technology needs for those missions. Lunar architectures have been identified and addressed by the Lunar Surface Systems team to establish options for how to get to, and then inhabit and explore, the moon. This paper will evaluate the options for exploration of space for the implications of architectures on the Environmental Control and Life Support (ECLSS), Thermal Control (TCS), and Extravehicular Activity (EVA) Systems.

Chambliss, Joe↗

Flight and Direct to Earth/Space Relay Communication System Architecture for GSFC CubeSat Missions

The CubeSat platform is finding increasing use in space science applications due to its low cost and comparative ease of launch. It is becoming a key scientific discovery tool in low Earth orbit (LEO) and beyond, including geosynchronous equatorial orbit (GEO), the Lagrange Points, Lunar missions, and more. The increasing complexity of these missions and their scientific goals must be supported by equal advancements in communications technology. Higher data rates and greater reliability are required every year. However, the reduced Size, Weight, and Power (SWaP) constraints of CubeSat platforms introduce unique challenges in the area of satellite communications. There is currently a lack of communication equipment tailored specifically to the CubeSat platform. This lack of standardized, tested equipment extends development time and reduces mission confidence. Furthermore, missions utilizing the CubeSat platform are often subject to more difficult design constraints. Antenna placement, size, and pointing are often subordinate to the requirements of the payload instruments and mission goals. Traditional link margin estimation techniques are insufficient in these cases, as they emphasize worst case scenarios. In reality the actual link parameters may vary widely even during a single pass. This presents new challenges in predicting communications performance and scheduling ground station contacts, but also new opportunities for improving efficiency. This paper presents the integration, testing, and validation process for a new software defined radio (SDR) designed for the CubeSat platform in conjunction with Vulcan Wireless, Inc. The SDR is planned for use on 5 upcoming CubeSat missions at NASAs Goddard Space Flight Center (GSFC) including a Geosynchronous Transfer Orbit (GTO) mission and it may also serve as a standard and well-tested option for future missions by enabling a standardized, rapid and low cost CubeSat communication system network integration process. Detailed simulations have been developed to estimate the communication performance of these missions, taking the unique antenna placements and attitude behavior of each satellite into account. These simulations allow a much more accurate analysis of the expected link margin, which varies considerably during each pass for the NASA Space Relay (SR) and Direct to Earth (DTE) network. The modelling procedures are outlined, and the results are used to predict communications performance of the missions.

Space Networks↗

Delay-Tolerant Networking for Space Flight Operations: Design and Development

Interplanetary Overlay Network (ION) is an implementation of the Delay-Tolerant Networking (DTN) architecture that is specifically intended to be usable for interplanetary communications. As such, its design differs in several ways from that of other implementations including DTN2, the reference implementation of the DTN Bundle Protocol. This paper briefly reviews the constraints on interplanetary communication that argue against the suitability not only of most off-the-shelf Internet technology but also of many DTN implementations. It then describes the operational components of ION, including its implementations of both the Bundle Protocol and the Licklider Transmission Protocol, noting the ways in which they address those constraints. Features of the system are explained with reference to their counterparts in the Internet architecture. The paper concludes with some notes on ION testing experience to date and plans for additional development in the future.

Interplanetary Overlay Network (ION)↗

The Real Time Interactive Display Environment (RTIDE), a display building tool developed by Space Shuttle flight controllers

NASA's Mission Control Center, located at Johnson Space Center, is incrementally moving from a centralized architecture to a distributed architecture. Starting with STS-29, some host-driven console screens will be replaced with graphics terminals driven by workstations. These workstations will be supplied realtime data first by the Real Time Data System (RTDS), a system developed inhouse, and then months later (in parallel with RTDS) by interim and subsequently operational versions of the Mission Control Center Upgrade (MCCU) software package. The Real Time Interactive Display Environment (RTIDE) was built by Space Shuttle flight controllers to support the rapid development of multiple new displays to support Shuttle flights. RTIDE is a display building tool that allows non-programmers to define object-oriented, event-driven, mouseable displays. Particular emphasis was placed on upward compatibility between RTIDE versions, ability to acquire data from different data sources, realtime performance, ability to modularly upgrade RTIDE, machine portability, and a clean, powerful user interface. The operational and organizational factors that drove RTIDE to its present form, the actual design itself, simulation and flight performance, and lessons learned in the process are discussed.

Kalvelage, Thomas A.↗

Access to space study

This report summarizes the results of a comprehensive NASA in-house study to identify and assess alternate approaches to access to space through the year 2030, and to select and recommend a preferred cause of action. The goals of the study were to identify the best vehicles and transportation architectures to make major reductions in the cost of space transportation (at least 50%), while at the same time increasing safety for flight crews by at least an order of magnitude. In addition, vehicle reliability was to exceed 0.98 percent, and, as important, the robustness, pad time, turnaround time, and other aspects of operability were to be vastly improved. This study examined three major optional architectures: (1) retain and upgrade the Space Shuttle and expendable launch vehicles; (2) develop new expendable vehicles using conventional technologies and transition from current vehicles beginning in 2005; and (3) develop new reusable vehicles using advanced technology, and transition from current vehicles beginning in 2008. The launch-needs, mission model utilized for for the study was based upon today's projection of civil, defense, and commercial mission payload requirements.

Source record↗

NASA's Implementation of Cloud Services for Human Space Flight

Cloud is a tried-and-true technology used throughout United States government agencies, including the National Aeronautics and Space Administration (NASA). With reliable results and infrequent downtimes, cloud allows for secure remote access, customizability, and streamlined monitoring options, creating an environment for better data integrity and availability. As NASA increasingly migrates functions to the cloud, the Space Communications and Navigation Program (SCaN) program has been investigating how this capability can be leveraged to provide communication services to its users and customers. Currently, missions such as NASA-ISRO Synthetic Aperture Radar (NISAR), Plankton, Aerosol, Cloud, ocean Ecosystem (PACE), and Roman Space Telescope (RST) are planned to incorporate cloud into their data delivery architecture. However, SCaN is looking to expand further. This conversion to using cloud services allows for greater availability of mission data for both robotic and human space flight (HSF)missions. The SCaN program and the Near Space Network (NSN) are working to consolidate resources and create a cloud environment suitable for the entirety of the SCaN program network architecture. SCaN is in the process of finalizing its cloud architecture and soon will be implementing cloud services. The new services used will adhere to federal regulations including Federal Risk and Authorization Management Program (FedRAMP), which is built upon National Institute of Standards and Technology (NIST)documentation. While keeping in mind these security requirements, an auxiliary objective of the cloud integration is to ensure the most cost-efficient solution; providing a scalable, robust and resilient system. Using cloud services, NASA will gain access to better centralized monitoring and management features, along with customizable services on a pay-per-use plan. With the ever-growing NASA mission data volume needs, maintaining ample storage space is another major constraint. Processing and storing such large amounts of data, on the order of terabytes a day, requires dynamic processing capability which is inherently a strength of cloud computing. By routing this data from ground stations through the cloud, there will be greater ease of access for both SCaN and the user community. Artificial intelligence and other built-in cloud functions can also enhance efficiency, improving data processing time. Thereby also allowing for better data availability. As we look to the future of cloud services, NASA will continue to leverage capabilities that will benefit NASA’s ability to provide cost-effective communication services. This paper further outlines the evolution of cloud use by SCaN in the context of Human Space Flight.

cloud storage↗

Next Steps: Laying the Groundwork for Bundle Protocol v7

Delay/Disruption Tolerant Networking (DTN) is a networking model and protocol suite that extends the terrestrial internet to the challenging communication environments of space. These environments are typically subject to frequent disruptions, which can cause delays or errors. DTN protects data transmission by wrapping data into bundles (similar to Internet Protocol packets), storing them until a connection can be established between two nodes (similar to terrestrial routers or computers), and forwarding them to their destinations. Bundle Protocol (BP) is responsible for generating those bundles and creates the transport layer of DTN, much like how Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) create the transport layer of the Internet Protocol. BPv6 is the current, accepted version of the Bundle Protocol standard. However, recent missions and test implementations have revealed missing components and areas for improvement in the standard. Using lessons learned from NASA missions and gathering inspiration from the Internet Protocol, BPv7 is intended to be a more robust Bundle Protocol that improves upon its predecessor and increases the technology readiness level of the DTN architecture. The DTN Standard Interface Design team, a sub-team of the DTN Infusion Project at the Goddard Space Flight Center, worked to create a dictionary of terms for bundle components and functional decomposition of the protocol. These efforts aided in the standardization of BP interfaces, something missing from BPv6, and supported parallel network management and configuration work. This standardization will ultimately contribute to LunaNet (a lunar communications and navigation architecture that will bring networking, positioning, navigation, timing and science services to the Moon), the Solar System Internet (SSI), and expand crewed and uncrewed space exploration opportunities.

DTN↗

Next Steps: Laying the Groundwork for Bundle Protocol v7

Delay/Disruption Tolerant Networking (DTN) is a networking model and protocol suite that extends the terrestrial internet to the challenging communication environments of space. These environments are typically subject to frequent disruptions, which can cause delays or errors. DTN protects data transmission by wrapping data into bundles (similar to Internet Protocol packets), storing them until a connection can be established between two nodes (similar to terrestrial routers or computers), and forwarding them to their destinations. Bundle Protocol (BP) is responsible for generating those bundles and creates the transport layer of DTN, much like how Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) create the transport layer of the Internet Protocol. BPv6 is the current, accepted version of the Bundle Protocol standard. However, recent missions and test implementations have revealed missing components and areas for improvement in the standard. Using lessons learned from NASA missions and gathering inspiration from the Internet Protocol, BPv7 is intended to be a more robust Bundle Protocol that improves upon its predecessor and increases the technology readiness level of the DTN architecture. The DTN Standard Interface Design team, a sub-team of the DTN Infusion Project at the Goddard Space Flight Center, worked to create a dictionary of terms for bundle components and functional decomposition of the protocol. These efforts aided in the standardization of BP interfaces, something missing from BPv6, and supported parallel network management and configuration work. This standardization will ultimately contribute to LunaNet (a lunar communications and navigation architecture that will bring networking, positioning, navigation, timing and science services to the Moon), the Solar System Internet (SSI), and expand crewed and uncrewed space exploration opportunities.

dtn↗

Avionics Architectures for Exploration: Building a Better Approach for (Human) Spaceflight Avionics

The field of Avionics is advancing far more rapidly in terrestrial applications than in space flight applications. Spaceflight Avionics are not keeping pace with expectations set by terrestrial experience, nor are they keeping pace with the need for increasingly complex automation and crew interfaces as we move beyond Low Earth Orbit. NASA must take advantage of the strides being made by both space-related and terrestrial industries to drive our development and sustaining costs down. This paper describes ongoing efforts by the Avionics Architectures for Exploration (AAE) project chartered by NASA's Advanced Exploration Systems (AES) Program to evaluate new avionic architectures and technologies, provide objective comparisons of them, and mature selected technologies for flight and for use by other AES projects. Results from the AAE project's FY13 efforts are discussed, along with the status of FY14 efforts and future plans.

Goforth, Montgomery B.↗

NASA's Small Spacecraft and Distributed Systems: Development and Demonstration of Technologies Enabling Swarms and New Spacecraft Platforms with AI and Edge Computing

NASA’s Small Spacecraft & Distributed Systems (SSDS) within the Research and Technology Mission Directorate (RTMD) expands U.S. capability to execute unique missions through targeted investment, rapid development, and flight demonstration of small spacecraft technologies applicable to exploration, science and the commercial space sector. SSDS strategically invests in technology development and on-orbit demonstrations executed across NASA, other government agencies, industry, and academia. The program’s University SmallSat Technology Partnerships initiative awards academic researchers with the opportunity to collaborate with NASA to mature innovative technology. Capabilities aligned with RTMD’s technology shortfalls and interests - power, processing, propulsion, sensors, communications, autonomous navigation, architectures, and advanced applications like artificial intelligence (AI), machine learning, and edge computing - are prioritized in SSDS investments. These investments enable distributed, autonomous, and cooperative small spacecraft systems that support swarm missions extending beyond low Earth orbit into cislunar and deep space. This paper highlights representative SSDS flight demonstrations that mature these capabilities to enable a future operational infrastructure needed to support sustained exploration of the Moon and beyond. SSDS’s investment strategy emphasizes rapid development and on-orbit demonstration to validate spacecraft technologies required for swarms and distributed mission architectures. The Starling swarm technology demonstration mission exemplifies this approach by advancing distributed spacecraft autonomy, cooperative operations, and space situational awareness. Extended flight testing and ongoing studies of next generation swarm configurations and on-orbit space traffic monitoring and management continue to inform future swarm designs. DiskSat’s four-spacecraft demonstration mission represents SSDS’s strategic vision to expand the design space for future small spacecraft through its commitment to advance novel platform concepts that can impact how science is performed on orbit. Continuing to invest in future platforms, the notional PY12 concept is a 12-spacecraft swarm hosting neuromorphic processors and is envisioned as an on-orbit testbed for AI, edge computing, and positioning, navigation and timing technologies. SSDS also invests in single-spacecraft technology demonstrations that underpin the success of future swarm missions and accelerate the availability of validated technologies across the small spacecraft ecosystem. Examples of such demonstrations include Pathfinder Technology Demonstrator-3 (PTD-3), which performed high-rate optical communications; PTD-R, which demonstrated a camera capable of simultaneous ultraviolet and short-wave infrared optical sensing; and CAPSTONE, the Cislunar Autonomous Positioning System Technology and Operations Navigation Experiment, which validated autonomous navigation in cislunar space. Collectively, SSDS-funded demonstrations advance capabilities across swarms and illustrate a coordinated investment strategy to mature high-impact technologies required for autonomous, distributed, and cooperative small spacecraft systems for low Earth orbit, cislunar, and deep space applications. Technology demonstrations strengthen SSDS partnerships with industry, academia, and other government agencies, and promote small spacecraft community adoption of capabilities required to close technical gaps for swarm missions.

Jan Stupl↗

NASA's Small Spacecraft and Distributed Systems: Development and Demonstration of Technologies Enabling Swarms and New Spacecraft Platforms with AI and Edge Computing

NASA’s Small Spacecraft & Distributed Systems (SSDS) within the Research and Technology Mission Directorate (RTMD) expands U.S. capability to execute unique missions through targeted investment, rapid development, and flight demonstration of small spacecraft technologies applicable to exploration, science and the commercial space sector. SSDS strategically invests in technology development and on-orbit demonstrations executed across NASA, other government agencies, industry, and academia. The program’s University SmallSat Technology Partnerships initiative awards academic researchers with the opportunity to collaborate with NASA to mature innovative technology. Capabilities aligned with RTMD’s technology shortfalls and interests - power, processing, propulsion, sensors, communications, autonomous navigation, architectures, and advanced applications like artificial intelligence (AI), machine learning, and edge computing - are prioritized in SSDS investments. These investments enable distributed, autonomous, and cooperative small spacecraft systems that support swarm missions extending beyond low Earth orbit into cislunar and deep space. This paper highlights representative SSDS flight demonstrations that mature these capabilities to enable a future operational infrastructure needed to support sustained exploration of the Moon and beyond. SSDS’s investment strategy emphasizes rapid development and on-orbit demonstration to validate spacecraft technologies required for swarms and distributed mission architectures. The Starling swarm technology demonstration mission exemplifies this approach by advancing distributed spacecraft autonomy, cooperative operations, and space situational awareness. Extended flight testing and ongoing studies of next generation swarm configurations and on-orbit space traffic monitoring and management continue to inform future swarm designs. DiskSat’s four-spacecraft demonstration mission represents SSDS’s strategic vision to expand the design space for future small spacecraft through its commitment to advance novel platform concepts that can impact how science is performed on orbit. Continuing to invest in future platforms, the notional PY12 concept is a 12-spacecraft swarm hosting neuromorphic processors and is envisioned as an on-orbit testbed for AI, edge computing, and positioning, navigation and timing technologies. SSDS also invests in single-spacecraft technology demonstrations that underpin the success of future swarm missions and accelerate the availability of validated technologies across the small spacecraft ecosystem. Examples of such demonstrations include Pathfinder Technology Demonstrator-3 (PTD-3), which performed high-rate optical communications; PTD-R, which demonstrated a camera capable of simultaneous ultraviolet and short-wave infrared optical sensing; and CAPSTONE, the Cislunar Autonomous Positioning System Technology and Operations Navigation Experiment, which validated autonomous navigation in cislunar space. Collectively, SSDS-funded demonstrations advance capabilities across swarms and illustrate a coordinated investment strategy to mature high-impact technologies required for autonomous, distributed, and cooperative small spacecraft systems for low Earth orbit, cislunar, and deep space applications. Technology demonstrations strengthen SSDS partnerships with industry, academia, and other government agencies, and promote small spacecraft community adoption of capabilities required to close technical gaps for swarm missions.

Jan Stupl↗

Suited Occupant Injury Potential During Dynamic Spacecraft Flight Phases

In support of the Constellation Space Suit Element [CSSE], a new space-suit architecture will be created for support of Launch, Entry, Abort, Microgravity Extra- Vehicular Activity [EVA], and post-landing crew operations, safety and, under emergency conditions, survival. The space suit is unique in comparison to previous launch, entry, and abort [LEA] suit architectures in that it utilizes rigid mobility elements in the scye (i.e., shoulder) and the upper arm regions. The suit architecture also utilizes rigid thigh disconnect elements to create a quick disconnect approximately located above the knee. This feature allows commonality of the lower portion of the suit (from the thigh disconnect down), making the lower legs common across two suit configurations. This suit must interface with the Orion vehicle seat subsystem, which includes seat components, lateral supports, and restraints. Due to the unique configuration of spacesuit mobility elements, combined with the need to provide occupant protection during dynamic vehicle events, risks have been identified with potential injury due to the suit characteristics described above. To address the risk concerns, a test series has been developed in coordination with the Injury Biomechanics Research Laboratory [IBRL] to evaluate the likelihood and consequences of these potential issues. Testing includes use of Anthropomorphic Test Devices [ATDs; vernacularly referred to as "crash test dummies"], Post Mortem Human Subjects [PMHS], and representative seat/suit hardware in combination with high linear acceleration events. The ensuing treatment focuses on test purpose and objectives; test hardware, facility, and setup; and preliminary results.

Dub, Mark O.↗