Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Knowledge Services Model”

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.

135 records · Page 8

Artificial Intelligence (AI) Methods for Augmenting the IMPACT Tool Evidence Library

Development of the Evidence Library for use with the IMPACT probability risk assessment tool took several years and involved a staggering amount of effort from a multi-disciplinary team. A very significant amount of the labor effort to collect, assess and finalize the Clinical Finding Form (CliFF) for each of the 119 medical conditions was provided by physician subject matter experts from the Exploration Medical Capability (ExMC) Element Clinical and Science Team. Many AI tools such as ChatGPT are excellent at summarizing large amounts of information and the current project was initiated to determine how such tools might streamline laborious processes, e.g., review and summarization of many scientific research publications, to execute key steps more efficiently in the process of developing CliFFs. The process for collecting the evidence which is found in the CliFFs is well documented in the Evidence Library Methods document (ELM; HRP-48036*). Using ELM and the CliFF development instructions as a guideline, a team of developers is leveraging Microsoft Azure AI tools and services along with open-source frameworks, to construct an AI-assisted automated pipeline. This pipeline is designed to search, retrieve, and process the necessary data sources, and ultimately help generate the final version of a CliFF. Currently, the large language model evaluates the relevance of each source material to spaceflights, either as direct evidence or as an analog. Additionally, the model assists in extracting keywords and generating brief summaries to enhance augmented retrieval and search processes in later stages of CliFF development. Once the data is ready, the model can perform semantic search and retrieval, generating and extracting valuable information for the CliFF. For instance, it can handle epidemiological statistical data, such as incidence rates and the likelihood of best or worst-case scenarios. The steps that required reading and summarizing articles were viewed as providing the greatest return on investment since large language models are very efficient and accurate in summarizing large amounts of text. Since labor effort to complete the original CliFF was not recorded with sufficient granularity, comparisons with an AI tool-generated CliFF will provide merely an approximation of time saved. Upon completion of the process, the CliFF for the medical condition “appendicitis” generated with the support of AI-based methods will serve as a proof-of-concept and will be compared to the original appendicitis CliFF to determine if use of the tools resulted in content and conclusory similarity. Based upon the results from face validation of the two CliFFs, modifications to the process will be made if necessary and additional condition CliFFs will be evaluated. Ultimately, CliFFs for the entire set of medical conditions will be created with the assistance of AI tools. Depending on the cost savings realized, CliFFs for additional medical conditions can be created to expand the Evidence Library. Future direction includes specifying the characteristics of the reviewer (prompting the AI tools to generate output assuming the reviewer is a sub-specialist physician, or nurse or EMT/medic) to determine if the effects on AI-generated output are different based on knowledge, skills and abilities. *Exploration Medical Capability Evidence Library Methods, HRP-48036 Rev A, July 2022.

Ali Al↗

Characterization of On-Orbit GPS Transmit Antenna Patterns for Space Users

The GPS Antenna Characterization Experiment (GPS ACE) has made extensive observations of GPS L1 signals received at geosynchronous (GEO) altitude, with the objective of developing comprehensive models of the signal levels and signal performance in the GPS transmit antenna side lobes. The experiment was originally motivated by the fact that data on the characteristics and performance of the GPS signals available in GEO and other high Earth orbits was limited. The lack of knowledge of the power and accuracy of the side lobe signals on-orbit added risk to missions seeking to employ the side lobes to meet navigation requirements or improve performance. The GPS ACE Project lled that knowledge gap through a collaboration between The Aerospace Corporation and NASA Goddard Space Fight Center to collect and analyze observations from GPS side lobe transmissions to a satellite at GEO using a highly-sensitive GPS receiver installed at the ground station. The GPS ACE architecture has been in place collecting observations of the GPS constellation with extreme sensitivity for several years. This sensitivity combined with around-the-clock, all-in-view processing enabled full azimuthal coverage of the GPS transmit gain patterns over time to angles beyond 90 degrees off-boresight. Results discussed in this paper include the reconstructed transmit gain patterns, with comparisons to available pre-fight gain measurements from the GPS vehicle contractors. For GPS blocks with extensive ground measurements, the GPS ACE results show remarkable agreement with ground based measurements. For blocks without extensive ground measurements, the GPS ACE results provide the only existing assessments of the full transmit gain patterns. The paper also includes results of pseudorange deviation analysis to assess systematic errors associated with GPS side lobe signals.

space↗

StarView: The object oriented design of the ST DADS user interface

StarView is the user interface being developed for the Hubble Space Telescope Data Archive and Distribution Service (ST DADS). ST DADS is the data archive for HST observations and a relational database catalog describing the archived data. Users will use StarView to query the catalog and select appropriate datasets for study. StarView sends requests for archived datasets to ST DADS which processes the requests and returns the database to the user. StarView is designed to be a powerful and extensible user interface. Unique features include an internal relational database to navigate query results, a form definition language that will work with both CRT and X interfaces, a data definition language that will allow StarView to work with any relational database, and the ability to generate adhoc queries without requiring the user to understand the structure of the ST DADS catalog. Ultimately, StarView will allow the user to refine queries in the local database for improved performance and merge in data from external sources for correlation with other query results. The user will be able to create a query from single or multiple forms, merging the selected attributes into a single query. Arbitrary selection of attributes for querying is supported. The user will be able to select how query results are viewed. A standard form or table-row format may be used. Navigation capabilities are provided to aid the user in viewing query results. Object oriented analysis and design techniques were used in the design of StarView to support the mechanisms and concepts required to implement these features. One such mechanism is the Model-View-Controller (MVC) paradigm. The MVC allows the user to have multiple views of the underlying database, while providing a consistent mechanism for interaction regardless of the view. This approach supports both CRT and X interfaces while providing a common mode of user interaction. Another powerful abstraction is the concept of a Query Model. This concept allows a single query to be built form a single or multiple forms before it is submitted to ST DADS. Supporting this concept is the adhoc query generator which allows the user to select and qualify an indeterminate number attributes from the database. The user does not need any knowledge of how the joins across various tables are to be resolved. The adhoc generator calculates the joins automatically and generates the correct SQL query.

Williams, J. D.↗

Designing Learning Experiences With A Low-Cost Robotic Arm

Robots have gained immense popularity in Hollywood and growth globally in both industrial manufacturing and non-manufacturing environments and applications such as healthcare, service sector, and space exploration. To date, there are several examples of simple and low-cost educational robotic platforms and commercially available platforms (e.g., Lego Mindstorms, VEX Robotics) for incorporation into existing curriculum. However, most low-cost examples require access to rapid-prototyping tools, such as 3D printers to manufacture the structure of the robot, while commercially available platforms are relatively expensive (> $1,000). Although the low-cost, open-source examples provide increased access, these examples require design and manufacturing tasks that would be considered outside the learning objectives of an upper-level robotics course and are better suited for other introductory courses. Thus, we asked, how can a robotic platform be incorporated into existing robotics curriculum to enhance students' learning experiences? To explore this research question, we introduce a low-cost (<$200), untethered, and transportable robotic platform that is easy to assemble using off-the-shelf components. This kit can be powered from a laptop computer and does not rely on access to rapid-prototyping tools such as 3D printers or laser cutters, making this a more accessible option in undergraduate engineering courses. Specifically, we aimed to investigate the design of experiential learning experiences for the mathematical modeling of the forward and inverse kinematics of a serial robotic arm that complements existing robotics curriculum. The experiential learning experience focuses on traditional written answer, simulation in MATLAB, and finally implementation on a robotic platform. Few studies examined this accessible option when evaluating experiential learning experiences that complement existing robotics curricula. To assess the impact of this robotic arm kit in an undergraduate course, we implemented an educational intervention that allowed us insight into student perceptions, takeaways on the course and activities involving the robotic arm, and the impact of the course on their career outlook when comparing activities that involved use of the robotic arm and those that did not. Details on the design, development and implementation of the learning activities is provided. Both quantitative and qualitative data were collected and analyzed. The results presented in this paper discuss students finding the learning activities on the robotic arms more helpful than those without, and that students found high value in the hands-on experiences and real-world scenarios offered by the activities using the robotic arm. Challenges to implementation of the robotic arms are discussed, including students’ prior knowledge of using robotic arms.

Eric J. Markvicka↗

Trajectory Engineering with Modular Patched Conics for Entry Systems and TPS (TEMPEST)

Brief Presenter Biography (35 word limit): Bohdan Wesely is an Aerospace Engineer in the Entry Systems and Technology Division at Ames. He has worked on a variety of projects for NASA including integrated TPS (thermal protection system) flight hardware deliveries and testing services for commercial partners. Introduction: TEMPEST is a new trajectory analysis framework that is designed to fill the gap between dedicated flight mechanics tools and aerothermal and TPS sizing tools. The project started as an SJSU master’s thesis and has since evolved into a general conceptual design tool capable of studying a wide variety of entry problems. Development is ongoing in the Entry Systems and Technology Division at NASA ARC. Why TEMPEST: Space missions involving entry into a planetary atmosphere involve a series of unique requirements across multiple disciplines. Whether it is traditional entry descent and landing (EDL), or aerocapture, the vehicle must navigate to its target landing location or orbit state, and the TPS must protect the payload during entry. The design process typically involves iterative handoffs between various flight mechanics, flow solver, and material response level tools. During the early conceptual phase, a wide variety of feasible trajectories are simulated in a Monte Carlo scenario which broadly satisfy the mission or landing requirements. Next, computational fluid dynamics (CFD), direct simulation Monte Carlo (DSMC), and other flow solver analyses are performed at various key trajectory points to generate an aero-database, heating and TPS design requirements also emerge at this stage. At this point, with updated aerodynamics from the various flow solvers, trajectories can be re-run, this in turn can change the required freestream conditions for the CFD tools, and as a project progresses, these analyses converge, and uncertainty is reduced. However, there is always a “hand-off” occurring between two inherently coupled phenomena. Analysis Description: One of the goals with TEMPEST is to use a variety of first principles estimation methods coupled with an atmosphere model to predict vehicle aerothermodynamics across the entire flight regime while propagating a 3 or 6 degree of freedom (DoF) trajectory. Aerodynamics methods include modified Newtonian, Maxwell and Cercignani- Lampis-Lord (CLL) for continuum, transitional, and free molecular flow regimes. Aerothermodynamics include boundary layer and reference enthalpy methods, and Mutation++ for non-equilibrium chemistry modeling. TEMPEST is also capable of stitching multiple trajectory segments together to study mission scenarios like multi-pass aerocapture and aero-gravity assists. Most of the program is implemented in MATLAB using modern system objects, it relies on several C++ shared libraries for supporting tools like Gmsh, the Global Reference Atmospheric Model (GRAM), and Mutation++. The various first principles aerothermal estimation methods are discretized across either a structured axisymmetric panel mesh or an unstructured tri-mesh generated from an open-source tool such as Gmsh, this allows solutions on the same mesh to be compared across tools such as CB-Aero. CFD Coupling. A physics-aware, gaussian process CFD anchoring scheme is proposed to adjust the various first principles methods as a CFD database is populated. One goal for this anchoring module is to inform the project where CFD should be run. Full knowledge of the entire trajectory, atmosphere, and aerothermodynamics allows for easier identification of high sensitivity areas and uncertainty quantification. While the first principles effects are well known and proven accurate in existing tools such as CB- Aero and Cart3D, a physics aware CFD anchoring scheme increases tool credibility across a project lifecycle. Material Response Modeling. Correct TPS sizing is critical for optimizing mass for science payloads and ensuring mission success. The process typically involves a thermal analysis along the trajectory with surface heating environments as a boundary condition. Several design constraints are maximum bondline temperature and maximum recession with various margining techniques. The material response tool FIAT, developed out of NASA Ames, is currently being integrated into the TEMPEST environment. TPS recession, shape change, mass loss, and mass property alteration are all factors that can perturb an entry trajectory. For missions like Mars 2020, recession was minimal and was safely handled separately as a post process. For missions such as Jupiter Galileo with a high TPS mass fraction or asteroid entries, recession plays a major role. The proposed fully coupled scheme is to use an epoch-based approach where the trajectory integration is halted after a recession threshold, the energy balance and FIAT are solved at each panel, the mesh, aerodynamics, and mass properties are updated, and the trajectory continues. Several computational tradeoffs have been made during the development of TEMPEST to limit the cost of a single trajectory and preserve its utility as a conceptual, rapid iteration tool. Conclusion: Development of TEMPEST is ongoing and the project is still in its infancy. This talk aims to showcase its unique capabilities to support future NASA entry systems missions.

Bohdan O Wesely↗

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

Investigating Low-Altitude Constellations of Ad-Hoc Lunar PNT System for Distributed Spacecraft Autonomy

In this study, we examine a low-altitude Lunar Position, Navigation, and Timing (LPNT) constellations and the localization performance of Centralized Extended Kalman Filter (CEKF) and Decentralized Extended Kalman Filter (DEKF) algorithms. The primary investigation involves a 100-node swarm operating at a 100 km altitude, in contrast to previous studies that examined a 21-node asset in a frozen-orbit at 5,500 km. The autonomous operation of large-scale swarm is based on two-way Inter-Satellite Link (ISL) measurements, which involve pseudoranges and relative velocities among swarm nodes. We perform a numerical assessment of the two filtering approaches, utilizing ‘fully sampled’ measurements from all available assets as well as ‘two ISL’ measurements where each spacecraft is restricted to only two antennas. This research includes an analysis of CEKF under 2-ISL constraints and evaluates the performance of DEKF in a 100-node swarm, which has not been explored in previous studies. In addition, we examine the impact of increasing the sampling frequency for DEKF, showing that the update cycle can be shortened from a 10-minute interval. A novel approach for ‘2-ISL limited’ DEKF will also be introduced, using a matching formulation that exhaustively enumerates all potential matches. This study provides valuable insights into large-scale distributed swarm operations, considering various filter configurations, sampling frequencies, matching strategies, and scalability of CEKF and DEKF for low-altitude LPNT applications. The Lunar PNT technology plays a key role in providing reliable and robust navigation services on the Moon's surface and the South pole, where the primary Lunar missions are planned. To support upcoming Lunar missions, including small satellites from NASA's Commercial Lunar Payload Services program, the Lunar PNT system must be adaptable to smaller platforms like CubeSats. Driven by the growing involvement of public and private exploration partnerships, the traditional low Earth orbit missions are shifting to beyond geosynchronous orbit [1]. These upcoming missions aim to foster a sustainable and innovative exploration program, in collaboration with commercial and international partners, to facilitate human expansion throughout the solar system and return new knowledge and opportunities to Earth [2]. As part of this trend, there are increasing efforts to utilize science missions in Lunar orbit to develop a non-dedicated and ad-hoc PNT network system. Two traditional approaches, the Deep Space Network (DSN) and the weak signal Global Positioning System (GPS), are established deep-space navigation technologies for missions beyond the geosynchronous orbit. Beginning in 1958, the DSN was developed to communicate with the Explorer 1 spacecraft based on the use of radiometric tracking in spacecraft navigation [3]. The DSN is capable of providing nearly unfettered coverage to spacecraft beyond low-Earth orbit (LEO), however, increased space mission volume has created concerns about future expectations of DSN usage for spacecraft navigation [4]. For cislunar mission applications, the position accuracy using DSN achieves 100 m (3σ) with at least three geometrically diverse ground stations when using radiometric tracking alone [5]. The DSN's dependence on Earth-based ground stations restricts its operational capabilities to periods of Earth visibility. This limitation, coupled with its poor localization performance, renders the DSN unsuitable for future lunar missions that demand continuous tracking and precise positioning. To satisfy the increasing requirements of DSN in Lunar applications, spacecrafts are also required to improve their onboard antenna power and efficiency of the transmission. However, there is an important aggregate cost trade between adding capabilities to every spacecraft and adding to a capacity on the ground that serves multiple spacecraft [6]. A weak GPS system can provide PNT service while the user spacecraft is bound to the Moon, leveraging a single, steerable high gain antenna with the relatively narrow beam which includes all the sources in its field of view [7]. However, the higher the altitude the receiver is above the GPS constellations, the poorer and the weaker are the relative geometry and the received signal powers, respectively, leading to a significant navigation accuracy reduction [8]. The transmitted power becomes weaker with increasing distance from the Earth as well as signals tracked from one of the side lobes of the GPS antenna pattern. As a results, the number of visible satellites and relative geometric condition of the GPS satellites at very high altitude drops dramatically and reduces the navigation solution accuracy. Therefore, the weak GPS system is also not an ideal way to provide PNT service to upcoming Lunar missions when considering its limited geometric condition and the recued navigation accuracy. Another navigation approach on the Moon is being developed, similar to the Global Navigation Satellite System (GNSS) on Earth, aiming to offer navigation service with continuous 24/7 coverage across the entire Lunar surface. For example, lunar communications relay and navigation systems (LCRNS) by NASA and Lunar navigation satellite systems (LNSS) by JAXA are designed to serve as dedicated Position, Navigation, and Timing (PNT) systems for the Moon. However, designing a dedicated LNSS and PNT service involves additional challenges, which are unique to the lunar environment, including limited payload capacity for the CubeSat platform, i.e., the size, weight, and power (SWaP) of the onboard clock, limited lunar ground monitoring stations, and limited financial investment as compared to the legacy Earth-GPS [9]. NASA’s focus on utilizing CubeSat platforms on the Moon leads to an alternative Lunar navigation platform that leverages the existing Lunar science and exploration assets. The small satellites used in Lunar missions can be used to create a low-cost, autonomous, ad-hoc, and on-demand mission-centric Lunar PNT swarm capable of providing PNT services to these low-cost lunar missions [10]. As upcoming Lunar missions will often operate at low-altitude about 30 km to 100 km for scientific observations and mapping purposes, the low-altitude orbital constellations could be employed to create an ad-hoc Lunar PNT system. However, several issues must be addressed, such as the instability of these orbits, which often require maintenance or are only suitable for short-duration missions, operating for fewer than 90 days. Additionally, at an altitude of 100 km, the satellites have a limited period during which they are above the horizon and capable of providing PNT service to users. The implementation of a non-dedicated, ad-hoc Lunar navigation constellation facilitates on-demand PNT services. A preliminary study of ad-hoc Lunar PNT system was conducted using 21 spacecraft in 5,5000 km altitude frozen orbits to test its feasibility and a basic performance of orbital asset localization among ad-hoc Lunar constellations in small satellites format [10]. These swarm assets are designed for autonomous localization with minimal Earth interaction, reducing dependency on bandwidth and ground resources. The design in [10] demonstrated the feasibility of a decentralized PNT approach, specifically employing a DEKF approach for state estimation, which helps minimize onboard operating costs. The DEKF method distributes computation across individual satellites, which lightens the computational load while maintaining accuracy in orbit ephemeris and clock offsets, similar to centralized systems [11]. In a follow-on study [12], each spacecraft was limited to 2 communications antennae, forcing the selection of measurements and scheduling spacecraft activities to perform the measurements. A matching algorithm is implemented to select the best measurements and schedule position estimation updates. The decentralized localization performance is also investigated with increasing levels of network degradation for swarm assets considering the impact of intermittent and permanent communication failure, to demonstrate the robustness and fidelity of the decentralized Lunar PNT service [13]. This study confirmed that the ad-hoc PNT constellations in frozen orbit are highly robust and resilient to communication failures. However, unlike frozen orbit swarm assets, the low-altitude satellites have a limited ground view at an altitude of 100 km, where the ad-hoc Lunar constellation consists of 98 low-altitude satellites, evenly distributed across seven circular polar orbital planes, alongside two satellites in a frozen orbit at an altitude of 5,500 km (Figure 1). Therefore, the number of satellites visible to ground users is significantly limited in low-altitude orbit constellations. As each visibility of a spacecraft remains intact for only a few ticks before it moves out of the field of view, the ground user encounters challenges in maintaining continuous navigation service, resulting in sparse availability and provision of Lunar PNT system. Consequently, service availability is primarily restricted to the Lunar South Pole region (Figure 2). Given these limitations and concerns, the localization performance of low-altitude swarm assets will be assessed in this study. We focus on the investigation of the localization performance of low-altitude swarm assets and ground users near the Lunar South Pole. The overall flow of the Lunar PNT simulation incorporates the DEKF approach of asset localization and the weighted least-squares approach in user localization (Figure 3). The autonomous Lunar PNT simulation is primarily implemented in MATLAB, where the DEKF based on the matching scheduler is implemented with Google’s OR-tools as a model builder and Gurobi optimization tool as a backend solver. The General Mission Analysis Tool (GMAT) is utilized to generate ephemeris data for swarm assets, and accounts for satellite orbital details, mass, and perturbations like solar radiation pressure and drag coefficients. Each ephemeris dataset is produced in the Moon International Celestial Reference Frame (ICRF) inertial coordinate system. For state estimation, the distributed swarm assets rely on two-way Inter-Satellite Link (ISL) measurements, which involve tracking pseudoranges and relative velocities between visible satellites and anchor nodes during each observation. Numerical evaluations of the decentralized localization process are conducted to demonstrate the feasibility of the low-altitude PNT system in providing reliable navigation services. The main approach involves using DEKF and CEKF to localize 100 satellites in low-altitude constellations, where the CEKF is implemented to serve as a baseline for comparing the performance of distributed algorithms. In both cases, we evaluate ‘fully sampled’ measurements from all available assets, and ‘two ISL’ measurements when spacecraft are constrained to have only two antennas. We test four estimation techniques: CEKF fully sampled, CEKF two ISL, DEKF fully sampled, and DEKF two ISL filters. As the DEKF update cycle is comprised of network setup, communication, and computations, a global broadcast network and 2-way ISL network setup will take from 4 to 6 minutes as maximum [12]. In this simulation, the DEKF update cycle is set to 10 minutes, including a 4-minute latency for obtaining and computing the actual measurement updates. We experiment an increased update cycle to demonstrate the feasibility and evaluate the impact on localization performance using various tuning values for measurement noise covariances (Figures 4 and 5). By comparing centralized and decentralized approaches using a matching algorithm, we analyze the influence of cross-correlation factors in the covariance matrix, assuming 100% reliability of all assets and measurements. The increased frequency and the adjustments of tuning parameters reveal distinct error patterns between the two scenarios. The localization accuracy of the swarm assets and ground users is assessed by taking the median error across 100 assets and one ground user (84.9°S, 137.5°E) over 7-day simulation period (Table 1). Since the user localization accuracy is significantly affected by the performance of the swarm assets, it is crucial to maintain high localization accuracy within the swarm. This study will continue to explore decentralized filtering for autonomous LPNT operations, with further investigation of an 'iterative' matching approach which enumerates every valid matching pair, planned for the following month.

Yeji Kim↗