SEARCH · Search NASA

Results for “core Flight System”

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.

SourceResearch connectionFrom yearThrough year

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

At least 55 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Developing A Dependable Multi-Agent Rover Swarm Using cFS

The future of space exploration lies in cooperative autonomous systems. Ensuring their high integrity remains a challenge. The Robust Software Engineering group at NASA Ames Research Center has been developing the Troupe project to explore the challenges with developing and assuring high integrity of cooperative autonomous robotic systems. In particular, Troupe aims to develop a swarm of autonomous rovers capable of mapping unknown terrain and assure their high integrity using the advanced V&V tools developed in the group. In this paper, we present the evolution of the design of Troupe. We focus on the lessons learned in developing and assuring the rover swarm using core Flight System (cFS). In particular, we discuss the benefits and challenges in applying model-based development to develop the rover swarm.

space systems↗

NASA NTRS2017

Application of CFS to a Lunar Rover: Resource Prospector (RP)

Resource Prospector (RP) is a lunar mission sponsored by NASA's Advanced Exploration Systems (AES) division, that aims to study in-situ resource utilization (ISRU) feasibility and technologies on the surface of the moon. The RP mission's lunar surface segment includes a rover equipped with with a suite of instruments specifically designed to measure and map volatiles both at the surface and in the subsurface. Of particular interest is the quantity and state of volatiles in permanently shadowed regions. To conduct the mission, ground system operators will remotely drive the rover, directing it to waypoints along the surface in order to achieve measurement objectives. At selected locations, an onboard drill will be deployed to collect material and obtain direct measurements of the subsurface constituents. RP is currently planned for launch in 2022. RP is managed at NASA Ames Research Center. The RP Rover is being designed and developed by NASA Johnson Space Center (JSC) in partnership with NASA Ames. NASA Kennedy Space Center (KSC) is responsible for the Honeybee drilling system and science payload. In order to better understand the technical challenges and demonstrate capability, in 2015 the RP project developed a rover testbed (known as RP15). In this mission in a year, a rover was designed, developed, and outfitted with science instruments and a drill. The rover was operated from a remote operations center, and operated in an outdoor lunar rock yard at Johnson space center. The study was a resounding success meeting all objectives. The RP Rover software architecture and development processes were based on the successful Lunar Atmosphere and Dust Environment Explorer spacecraft. This architecture is built on the Core Flight System software and an interface to Matlab/Simulink auto-generated software components known as the Simulink Interface Layer (SIL). The application of this lunar satellite inspired framework worked well for the rover application, and is currently being planned for the mission. This presentation provides an overview of the architecture and processes, and describes some of the changes and challenges for the rover application.

RP↗

NASA NTRS2015

Pi-Sat: A Low Cost Small Satellite and Distributed Spacecraft Mission System Test Platform

Current technology and budget trends indicate a shift in satellite architectures from large, expensive single satellite missions, to small, low cost distributed spacecraft missions. At the center of this shift is the SmallSatCubesat architecture. The primary goal of the Pi-Sat project is to create a low cost, and easy to use Distributed Spacecraft Mission (DSM) test bed to facilitate the research and development of next-generation DSM technologies and concepts. This test bed also serves as a realistic software development platform for Small Satellite and Cubesat architectures. The Pi-Sat is based on the popular $35 Raspberry Pi single board computer featuring a 700Mhz ARM processor, 512MB of RAM, a flash memory card, and a wealth of IO options. The Raspberry Pi runs the Linux operating system and can easily run Code 582s Core Flight System flight software architecture. The low cost and high availability of the Raspberry Pi make it an ideal platform for a Distributed Spacecraft Mission and Cubesat software development. The Pi-Sat models currently include a Pi-Sat 1U Cube, a Pi-Sat Wireless Node, and a Pi-Sat Cubesat processor card.The Pi-Sat project takes advantage of many popular trends in the Maker community including low cost electronics, 3d printing, and rapid prototyping in order to provide a realistic platform for flight software testing, training, and technology development. The Pi-Sat has also provided fantastic hands on training opportunities for NASA summer interns and Pathways students.

Software↗

NASA NTRS2021

Software Approach for the Regenerative Fuel Cell Project

The Regenerative Fuel Cell (RFC) project is developing a system that combines a fuel cell subsystem for energy production with an electrolysis subsystem for energy storage. The system is primarily being developed at the Glenn Research Center with support from Johnson Space Center under the Space Technology Mission Directorate / Game Changing Development Program. Currently, the intent is to operate the RFC system in an equivalent environment to a lunar equator location for a period of several lunar day/night cycles with minimal operator input. Demonstrating an automated RFC system in this environment is a step towards showing the extensibility to a flight system. This paper describes the RFC software team’s approach for development of the monitoring and control software that allows for the automated operation of the RFC system. We describe the rationale for the choice of Core Flight System architecture, as well as the plan for software/hardware integration.

Mathew J Mccaskey↗

NASA NTRS2019

Model-based System Health Management and Contingency Planning for Autonomous UAS

Safe autonomous operations of an Unmanned Aerial System (UAS) requires that the UAS can react to unforeseen circumstances, for example, after a failure has occurred. In this paper we describe a model-based run-time architecture for autonomous on-board diagnosis, system health management, and contingency management. This architecture is being instantiated on top of NASA's Core Flight System (cFS/cFE) as amajor component of the on-board AutonomousOperating System (AOS). We will describe our diagnosis and monitoring components, which continuously provide system health status. Automated reasoning with constraint satisfaction form the core of our decision-making component, which assesses the current situation, aids in failure disambiguation, and constructs a contingency plan to mitigate the failure(s) and allow for a safe end of the mission. We will illustrate our contingency management system with two case studies, one for a fixed-wing aircraft in simulation, and one for an autonomous DJI S1000+ octo-copter.

Schumann, Johann M.↗

NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗

NASA NTRSDate not supplied

Low SWaP Onboard Satellite Navigation, Guidance, and Control Technology

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The first build of autoNGC, providing autonomous navigation for lunar orbiting spacecraft, is targeted for completion by Fall 2024. It provides sensor fusion of multiple measurement types including pseudo-range from a weak signal Global Navigation Satellite Service (GNSS) receiver, 1-way and 2-way direct to Earth (DTE) range and Doppler, bearing and range from optical camera sensed images, and an accelerometer. AutoNGC is also being targeted for future missions that involve small body proximity operations, Sun Earth Libration point orbits, and distributed systems missions (DSMs) including those at outer planets. AutoNGC flight software is being built upon the plug-and-play architecture of the core Flight System (cFS) [Ref. 1]. Figure (Slide 7) shows the message-based software bus layout of various software applications (“apps”) consisting of the standard cFS apps and autoNGC interface apps and libraries. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library [Ref. 2], which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are provided by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app [Ref. 3]. This app processes optical images to extract the bearing angles of the centroid of the imaged body (near or far), the range to the imaged body, and/or of the features on the surface of a body to perform terrain relative navigation (TRN). Measurement of range to the body’s center of mass can also be derived from the detection of the limb. The first build of autoNGC for a lunar orbiting spacecraft is a minimal size, weight, and power (SWaP) hardware design allowing for inclusion into CubeSats and SmallSat-size class buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z [Ref. 4] are utilized for low SWaP while maintaining a high level of performance. Figure (Slide 11) shows the composition of the first autoNGC build. The current enclosure design has dimensions 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. The hardware interfaces are designed for flexibility with a variety of sensor inputs. The achievable navigation performance depends on the sensors utilized, including the onboard clock for 1-way pseudo-range measurements. Analysis using a configuration that consists of weak signal GPS, TRN, and 1-way DTE has shown position and velocity accuracies of 10 meters and 2 cm/s (3-σ ) RSS, respectively, with onboard time knowledge estimated to better than 13 ns (3-σ ), for a spacecraft in a representative 12-hour eccentric lunar orbit. Other measurement types such as x-rays from known pulsars (called XNAV) and cross-links can also be processed in GEONS. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced, even after launch. Goddard is actively seeking partners to collaborate in the development of additional capabilities for autoNGC, including industry, academia, and others across the US Government. Plans are being formulated to make the autoNGC software platform available for use by any US government organization to leverage the non-recurring engineering associated with the development of onboard autonomous NGC 3 capabilities. As advancements in space qualified sensors, microprocessors, and algorithms are made, the autoNGC platform provides a ready starting point for inclusion of these technologies.

C. J. Gramling↗

NASA NTRS2009

Architectural Analysis of Complex Evolving Systems of Systems

The goal of this collaborative project between FC-MD, APL, and GSFC and supported by NASA IV&V Software Assurance Research Program (SARP), was to develop a tool, Dynamic SAVE, or Dyn-SAVE for short, for analyzing architectures of systems of systems. The project team was comprised of the principal investigator (PI) from FC-MD and four other FC-MD scientists (part time) and several FC-MD students (full time), as well as, two APL software architects (part time), and one NASA POC (part time). The PI and FC-MD scientists together with APL architects were responsible for requirements analysis, and for applying and evaluating the Dyn-SAVE tool and method. The PI and a group of FC-MD scientists were responsible for improving the method and conducting outreach activities, while another group of FC-MD scientists were responsible for development and improvement of the tool. Oversight and reporting was conducted by the PI and NASA POC. The project team produced many results including several prototypes of the Dyn-SAVE tool and method, several case studies documenting how the tool and method was applied to APL s software systems, and several published papers in highly respected conferences and journals. Dyn-SAVE as developed and enhanced throughout this research period, is a software tool intended for software developers and architects, software integration testers, and persons who need to analyze software systems from the point of view of how it communicates with other systems. Using the tool, the user specifies the planned communication behavior of the system modeled as a sequence diagram. The user then captures and imports the actual communication behavior of the system, which is then converted and visualized as a sequence diagram by Dyn-SAVE. After mapping the planned to the actual and specifying parameter and timing constraints, Dyn-SAVE detects and highlights deviations between the planned and the actual behavior. Requirements based on the need to analyze two inter-system communication protocols that are representative of protocols used in the Aerospace industry have been specified. The protocols are related: APL s Common Ground System (CGS) as used in the MErcury Surface, Space ENvironment, GEochemistry, and Ranging (MESSENGER) and the Radiation Belt Space Probes (RBSP) missions. The analyzed communications were implementations of the Telemetry protocol and the CCSDS File Delivery Protocol (CFDP) protocol. Based on these requirements, three prototypes of Dyn-SAVE were developed and applied to these protocols. The application of Dyn-SAVE to these protocols resulted in the detection of several issues. Dyn-SAVE was also applied to several Testbeds that have previously been used for experimentation earlier on this project, as well as, to other protocols and logs for testing its broader applicability. For example, Dyn-SAVE was used to analyze 1) the communication pattern between a web browser and a web server, 2) the system log of a computer in order to detect offnominal computer shut-down behavior, and 3) the actual test cases of NASA Goddard s Core Flight System (CFS) and automatically generated test cases in order to determine the overlap between the two sets of test cases. In all cases, Dyn-SAVE assisted in providing insightful conclusions about each of the cases identified above.

Lindvall, Mikael↗

NASA NTRSDate not supplied

Rapid Lightweight Firmware Architecture of the Mobile Metamaterial Internal Co-Integrator Robot

The Mobile Metamaterial Internal Co-Integrator (MMIC-I) is a structure assembly and servicing robot for in-space servicing, assembly, and manufacturing of primary structures and infrastructure. MMIC-I is a battery-powered crawling robot that can travel through periodic structures such as trusses and open framework mechanical metamaterials. It does this through sequences of component extension, contraction, and gripping. This paper provides a detailed discussion of MMIC-I’s lightweight and rapidly developed firmware architecture, to enable demonstration of robot locomotion, secondary operations, and communications with a central command source. The rationale for the lightweight rapid development approach is to allow for assessment of long term system requirements in parallel with the mechatronics development, including optimization of system and subsystem power densities, to inform a future choice of flight ready software frameworks. MMIC-I system computing and I/O requirements are much lower than what is provided by proven baseline computing hardware for existing flight ready software frameworks such as the core Flight System, F prime, and the Robot Operating System. Development of earth gravity ground demonstration of the robotic systems is greatly benefited by limited power and mass factors for computing hardware. Here, we implement inter-process communication, commanding, and telemetry with the Espressif ESP32 module running the Arduino OS.

Damiana Catanoso↗

NASA NTRSDate not supplied

Autonomous Navigation, Guidance, and Control Software in a Low SWaP Box

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The autoNGC flight software is built on the plug-and-play architecture of the core Flight System (cFS) consisting of the standard cFS apps and newly developed autoNGC interface apps and libraries. The various apps cooperate through communication over the message-based software bus. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced to meet the needs of different missions, even after launch. The first flight software release of autoNGC is targeted for Summer 2024 to provide autonomous navigation at the Moon and beyond. It can perform sensor fusion of multiple measurement types including pseudo-range from a Global Navigation Satellite System (GNSS) receiver (including weak signal), 1-way and 2-way range and Doppler from ground stations (i.e., direct to Earth (DTE)), bearing and range from optical camera images, and accelerometer data. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are first extracted from optical images by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app. If the imaged body is far enough away that it appears as a pixel or cluster of pixels, then bearing angles to the body centroid can be provided. If the body is close enough and the shape is known coarsely, then bearing angles and range to the body centroid can be derived from the limb. Bearing angles to individual surface features can also be extracted (i.e., terrain relative navigation (TRN)). Onboard guidance and control capabilities are being developed for a future release to perform autonomous station-keeping and trajectory correction maneuvers in multiple orbital regimes. Capabilities to enable distributed systems missions and constellations, such as crosslink measurements, and onboard time management are being developed as well. The first hardware implementation of autoNGC is a minimal size, weight, and power (SWaP) design allowing for inclusion into CubeSats and SmallSat-size buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z are utilized for low SWaP while maintaining a high level of performance. The current enclosure design is 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. In order to accommodate a wide range of missions, the hardware interfaces are designed for flexibility with a variety of sensor inputs. Through comprehensive testing in the software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop test beds that are concurrently being developed, autoNGC is expected to achieve TRL 6 by late 2024.

Sun Hur-Diaz↗

NASA NTRS2017

Study of Tools for Command and Telemetry Dictionaries

The Command and Telemetry Dictionary is at the heart of space missions. The C&T Dictionary represents all of the information that is exchanged between the various systems both in space and on the ground. Large amounts of ever-changing information has to be disseminated to all for the various systems and sub-systems throughout all phases of the mission. The typical approach of having each sub-system manage it's own information flow, results in a patchwork of methods within a mission. This leads to significant duplication of effort and potential errors. More centralized methods have been developed to manage this data flow. This presentation will compare two tools that have been developed for this purpose, CCDD and SCIMI that were designed to work with the Core Flight System (cFS).

Command Telemetry Dictionary C&↗

NASA NTRSDate not supplied

Advancing Autonomy in Distributed Space Systems: Insights From on-Orbit Testing with the Starling 1.0 Mission

Autonomous decision-making is crucial for enhancing mission effectiveness in Distributed Space Systems (DSS), particularly in multi-spacecraft operations where communication constraints and mission complexity pose challenges. The Distributed Spacecraft Autonomy (DSA) team at NASA’s Ames Research Center is advancing autonomy in DSS through five key technical areas: distributed resource and task management, reactive operations, system modeling and simulation, human-swarm interaction, and ad hoc network communications. The DSA experiment onboard the Starling 1.0 Mission showcases collaborative resource allocation for multi-point science data collection with four small spacecraft. Autonomy in decision-making is highlighted as a crucial factor for multi-spacecraft missions, enabling spacecraft to operate independently, reducing reliance on ground control. This capability is particularly significant for future deep-space missions, where communication delays and limited data transmission capacity make traditional command and control approaches impractical. This demonstration focuses on a GPS Channel Selection Experiment, leveraging emergent capabilities like "shared sampling" and "simultaneous sampling" to optimize channel selection across the spacecraft swarm. The experiment aims to capture ionospheric phenomena such as the Equatorial Ionization Anomaly and Polar Patches. The DSA system's autonomous reconfiguration ability is showcased, emphasizing its adaptability to natural phenomena without significant integration efforts. The GPS Channel Selection Experiment utilizes a dual-band GPS receiver to estimate plasma density in the ionosphere. Explorative and exploitative channel selections are employed based on the nature of observed phenomena. The performance of DSA algorithms is evaluated in terms of optimal channel allocations and responsiveness to changes in observed features. The DSA Flight Software utilizes the Core Flight System (cFS) framework, ensuring compatibility with the Starling 1.0 flight mission software. DSA showcases results from RTI’s Connext DDS Micro communication middleware, enabling message routing over the Ad-Hoc Network of Starling 1.0. This paper provides a comprehensive overview of the DSA experiment's initial results, emphasizing the advancements in autonomy for Distributed Space Systems and the successful collaboration with the Starling 1.0 mission.

Caleb Ashmore Adams↗

NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗

NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospaceâ€"TM"s command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for userâ€"TM"s to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

McComas, David↗

NASA NTRSDate not supplied

Dynamic Assurance of Autonomous Systems through Ground Control Software

Assurance cases are being increasingly acknowledged as a way to build trust in complex systems with autonomous capabilities [1]. An assurance case is a comprehensive, defensible, and valid justification that a system will function as intended for the specific mission and operating environment. Such justifications for systems with autonomous capabilities are often based on various probabilistic quantifications [2]. Due to the dynamic nature of the environmental conditions in which these systems operate, as well as the changing nature of the autonomous systems themselves, these probabilistic quantifications cannot be simply estimated once during design time. Rather, they need to be continually evaluated during systems operations to ensure that the assurance case justifications are valid. We refer to the assurance case that combines both the static and dynamic elements as a Dynamic Assurance Case (DAC). Such complex systems with autonomous capabilities are often deployed with a Ground Control Software (GCS) component to enable remote operation. Whether the system is composed of a single unit or a fleet of units, deployed distributed or in remote environments, GCS acts as a window into the behavior of the deployed system. It receives telemetry from the system, issues commands to the system and provides various functionalities to visualize the system performance. We propose a dynamic assurance framework where the GCS acts as a relay between the autonomous system and its DAC. GCS can be used to measure both unit-specific as well as system-wide probabilistic quantifications using the incoming telemetry. We embed these quantifications throughout the DAC as variables that can be updated by external sources. We use the GCS to periodically update these variables, which allows us to continually evaluate the formally defined assurance case justifications. We demonstrate our dynamic assurance framework in the NASA Ames project Troupe1 that aims at developing a fleet of rovers capable of au- tonomously mapping their environment. The rovers work cooperatively, each collecting data for different parts of the environment. Each rover runs an identical core Flight System (cFS) [4] application. Troupe1 uses OpenC3 Cosmos [5] as the ground system, and AdvoCATE [3] to capture the system DAC. We show how we can measure both rover-specific and system-wide quantifications in Cosmos using its Ruby scripting editor and pass them into the DAC modelled in AdvoCATE. Then, we show how these incoming variables can be embedded in different parts of the DAC and how effects of their updates can be observed

Irfan Sljivo↗

NASA NTRS2006

Evolving EO-1 Sensor Web Testbed Capabilities in Pursuit of GEOSS

A viewgraph presentation to evolve sensor web capabilities in pursuit of capabilities to support Global Earth Observing System of Systems (GEOSS) is shown. The topics include: 1) Vision to Enable Sensor Webs with "Hot Spots"; 2) Vision Extended for Communication/Control Architecture for Missions to Mars; 3) Key Capabilities Implemented to Enable EO-1 Sensor Webs; 4) One of Three Experiments Conducted by UMBC Undergraduate Class 12-14-05 (1 - 3); 5) Closer Look at our Mini-Rovers and Simulated Mars Landscae at GSFC; 6) Beginning to Implement Experiments with Standards-Vision for Integrated Sensor Web Environment; 7) Goddard Mission Services Evolution Center (GMSEC); 8) GMSEC Component Catalog; 9) Core Flight System (CFS) and Extension for GMSEC for Flight SW; 10) Sensor Modeling Language; 11) Seamless Ground to Space Integrated Message Bus Demonstration (completed December 2005); 12) Other Experiments in Queue; 13) Acknowledgements; and 14) References.

Mandi, Dan↗

NASA NTRSDate not supplied

Celestial Navigation in Cislunar Space with autoNGC

Celestial navigation (CelNav) is a source of navigation observables where images of known solar system bodies are used to locate a spacecraft, beneficial within the solar system for both cislunar and deep space missions. CelNav provides a variety of design benefits to support and enable current and new autonomous space operations- using only a camera and a processor to produce in-situ measurements for navigation. This technology reduces subscription to ground-based tracking during all phases of a mission, freeing up resources for other operational needs. This also supports secure navigation since it eliminates the need for ground contact. CelNav enables missions where the light time delay between Earth and the spacecraft is too long (or the Earth to spacecraft line of sight is obscured) to support critical operations. It also enables smaller mission classes, where Deep Space Network (DSN)time is cost prohibitive, to reduce its cost by focusing primarily on data downlink. Finally, it enables the NASA Artemis program and other cislunar human space flight by providing redundant navigation to traditional radiometric tracking. In this presentation, we discuss the implementation of a CelNav app in autonomous Navigation, Guidance, and Control (autoNGC), a comprehensive flight software suite for onboard autonomy that is built on the core Flight System (cFS). The presentation also summarizes the results of flight software-in-the-loop (SIL) and processor-in-the-loop (PIL) demonstrations. Both are high-fidelity simulations with the use of a camera emulator hosted on a GPU server that simulates images that would be captured by the camera. The CelNav app leverages the use of cGIANT (cFS Goddard Image Analysis and Navigation Tool).Previously developed for the autoNGC software suite, cGIANT is an onboard autonomous image processing and optical navigation (OpNav) tool that performs limb-based OpNav and Terrain Relative Navigation. The added CelNav capability of cGIANT generates bearing measurements to multiple known celestial bodies (planets, moons, asteroids, comets, etc.) in monocular (2D) images. These observables are then fed to the Goddard Enhanced Onboard Navigation System (GEONS)navigation filter app, enabling us to navigate the spacecraft autonomously. In early 2025, the autoNGC CelNav capability is planned to be flight tested as part of the onboard autonomy experiment on the Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment(CAPSTONE) spacecraft that is currently in a Lunar Near Rectilinear Halo Orbit(NRHO).

celestial navigation↗

NASA NTRS2006

Using Existing NASA Satellites as Orbiting Testbeds to Accelerate Technology Infusion into Future Missions

One of the shared problems for new space mission developers is that it is extremely difficult to infuse new technology into new missions unless that technology has been flight validated. Therefore, the issue is that new technology is required to fly on a successful mission for flight validation. We have been experimenting with new technology on existing satellites by retrofitting primarily the flight software while the missions are on-orbit to experiment with new operations concepts. Experiments have been using Earth Observing 1 (EO-1), which is part of the New Millennium Program at NASA. EO-1 finished its prime mission one year after its launch on November 21,2000. From November 21,2001 until the present, EO-1 has been used in parallel with additional science data gathering to test out various sensor web concepts. Similarly, the Cosmic Hot Interstellar Plasma Spectrometer (CHIPS) satellite was also a one year mission flown by the University of Berkeley, sponsored by NASA and whose prime mission ended August 30,2005. Presently, CHIPS is being used to experiment with a seamless space to ground interface by installing Core Flight System (cFS), a "plug-and-play" architecture developed by the Flight Software Branch at NASA/GSFC on top of the existing space-to-ground Internet Protocol (IP) interface that CHIPS implemented. For example, one targeted experiment is to connect CHIPS to a rover via this interface and the Internet, and trigger autonomous actions on CHIPS, the rover or both. Thus far, having satellites to experiment with new concepts has turned out to be an inexpensive way to infuse new technology for future missions. Relevant experiences thus far and future plans will be discussed in this presentation.

Mandl, Daniel↗