Search NASA⌕ Search

SEARCH · Search NASA

Results for “cFS”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS1995

The tonotopic map in the embryonic chicken cochlea

The purpose of the present study was to determine the tonotopic map in the chicken cochlea at 19 days of incubation (E19) by obtaining characteristic frequencies (CFs) for primary afferents, labeling the characterized neurons, and documenting their projections to the papilla. The lowest and highest CFs recorded were 188 and 1623 Hz respectively. The embryonic tonotopic map coincided with maps reported for post-hatch chicks. There were no evidence that neurons selective to low frequencies project inappropriately to more basal locations of the embryonic papilla. Linear regression was used to estimate the frequency gradient (b = 0.037 +/- 0.012 In Hz/% [b +/- SEb]) and intercept (In C, where C = 111 Hz) of the semilog plot of frequency versus cochlear position (in % distance from apex). From these estimates the octave distribution was calculated to be 18.7%/octave or 0.58 mm/octave. These quantities were not significantly different from those found in post hatch chickens. We conclude that the tonotopic map of the avian cochlea for CFs between 100 and 1700 Hz is stable and relatively mature from age E19 to post-hatch day 21 (P21). The most striking sign of immaturity in the E19 embryo is the limited range of high CFs. We offer the hypothesis that, between the ages of E19 and P21, improvements in middle ear admittance alone or in combination with functional maturation of the cochlear base may be the principal factors responsible for the appearance of adult-like high CF limits and not an apically shifting tonotopic map.

NASA Discipline Neuroscience↗
NASA NTRS2010

Architectural Analysis of Dynamically Reconfigurable Systems

oTpics include: the problem (increased flexibility of architectural styles decrease analyzability, behavior emerges and varies depending on the configuration, does the resulting system run according to the intended design, and architectural decisions can impede or facilitate testing); top down approach to architecture analysis, detection of defects and deviations, and architecture and its testability; currently targeted projects GMSEC and CFS; analyzing software architectures; analyzing runtime events; actual architecture recognition; GMPUB in Dynamic SAVE; sample output from new approach; taking message timing delays into account; CFS examples of architecture and testability; some recommendations for improved testablity; and CFS examples of abstract interfaces and testability; CFS example of opening some internal details.

Lindvall, Mikael↗
NASA NTRS2017

Porting the Core Flight System to the Dellingr Cubesat

Dellingr is a 6U Cubesat developed by NASA Goddard Space Flight Center. It was delivered to the International Space Station in August 2017, and is scheduled to be deployed in November 2017. Compared to a typical NASA satellite, the Dellingr Cubesat had an extremely low budget and short schedule. Although the Dellingr Cubesat has minimal hardware resources, the cFS was ultimately chosen for the flight software. Using the cFS on the Dellingr Cubesat presented a few challenges, but also offered opportunities to help speed up development and verify the ACS flight software. This presentation will cover the lessons learned in porting the cFS to the Dellingr Cubesat, including working with the limited hardware resources, porting the cFS to FreeRTOS, and overcoming limitations related to data storage and file transfer. This presentation will also cover how hardware abstraction was used to run the flight software on multiple platforms and interface with the 42 dynamic simulator.

flight softwar↗
NASA NTRSDate not supplied

Interfacial thermodynamics of cryogenic fluids: The effect on non-condensable gas on fluid storage

Propellant tanks that contain cryogenic fluids (CFs) in low gravity conditions are usually pressurized with non-condensable (NC) gases for fast extraction. Unfortunately, the presence of NC gases causes CFs to exhibit higher boil-offs compared to pure CF systems. For optimal utilization of the cryogenic fuels, these higher boil-off rates must be minimized. Our goal is to quantify the effects NC gases have on the evaporation and condensation dynamics of CFs to develop strategies that mitigate the higher boil-offs. The hypothesis is that the NC gas accumulates around the CF’s liquid vapor interface in the Knudsen layer, creating a kinetic barrier for both evaporation and condensation. Testing this hypothesis with experimental methods is difficult due to the transient nature of the Knudsen layer, which is only a few nanometers thick. Furthermore, experimental capabilities are limited in low gravity conditions and extremely expensive. Accordingly, we approach this problem from a theoretical perspective. In this study, we employ molecular dynamics (MD) simulations to probe the interfacial mechanisms that affect CF’s evaporation and condensation at varying concentrations of NC gases. Specifically, we use nitrogen (N2) and oxygen (O2) as our CFs and neon (Ne) as our NC gas. Using MD simulations, we show that Ne accumulates at N2 liquid vapor interface across a wide range of Ne concentrations, thereby impeding mass transport of N2. Our simulations allow for direct computation of the molar flux as well as the mass accommodation coefficient (MAC) which can then be used as input parameters to continuum fluid dynamics (CFD) models for optimal storage tank design.

Michael Robert DeLyser↗
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 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 NTRSDate not supplied

Data Definition Management for Orion Backup Flight Software

The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. Missions using cFS can reuse code from other missions, as well as leverage deployment to similar computer architectures. The Orion Backup Flight Software (BFS) team selected cFS as the architecture to be used on the program, and this presentation will describe some design choices we made, and the consequences of those decisions.

CFS↗
DOE OSTI2024

Summertime Continental Shallow Cumulus Cloud Detection Using GOES‐16 Satellite and Ground‐Based Ceilometer at North Alabama

Abstract Accurate simulations of boundary layer cloud processes remain challenging in Earth system modeling. Observations are essential to evaluate and improve models of such processes. This study introduces a comprehensive validation framework for a satellite‐based detection algorithm of continental shallow cumulus (ShCu) clouds during the daytime, which was initially developed using ground‐based observations of stereo cameras at the Department of Energy Atmospheric Radiation Measurement (ARM) Southern Great Plains site (J. Tian et al., 2021, https://doi.org/10.3390/rs13122309 , 2022, https://doi.org/10.1029/2021gl097070 ). To validate this algorithm, the framework employs ground‐based ceilometer measurements from North Alabama (NA) where ShCu populations are prevalent. This study first generates clear‐sky surface reflectance maps at NA and identifies ShCu pixels with a detection threshold using Geostationary Operational Environmental Satellite (GOES) reflectance data. The obtained cloud fractions (CFs) are then compared against CFs from a ground‐based ceilometer, considering factors such as observed area differences, satellite parallax issue, and systematic biases. We found that with a detection threshold (∆R) of 0.05, the ShCu detection algorithm is effective for NA, enabling the reproduction of hourly ShCu CFs using GOES. Our framework is straightforward and easily repeatable to evaluate the effectiveness of a ∆R threshold for detecting ShCu clouds in various geographic regions where ceilometers are deployed. This satellite detection of ShCu provides a crucial regional context for ground‐based measurements, facilitating the tracking of convection initiation and its coupling with land surface conditions. Integrating localized ground‐based and regional satellite data will enhance our ability to conduct thorough studies of cloud morphology and land‐atmosphere interactions in North Alabama.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2010

Cryogenic Flow Sensor

An acousto-optic cryogenic flow sensor (CFS) determines mass flow of cryogens for spacecraft propellant management. The CFS operates unobtrusively in a high-pressure, high-flowrate cryogenic environment to provide measurements for fluid quality as well as mass flow rate. Experimental hardware uses an optical plane-of-light (POL) to detect the onset of two-phase flow, and the presence of particles in the flow of water. Acousto-optic devices are used in laser equipment for electronic control of the intensity and position of the laser beam. Acousto-optic interaction occurs in all optical media when an acoustic wave and a laser beam are present. When an acoustic wave is launched into the optical medium, it generates a refractive index wave that behaves like a sinusoidal grating. An incident laser beam passing through this grating will diffract the laser beam into several orders. Its angular position is linearly proportional to the acoustic frequency, so that the higher the frequency, the larger the diffracted angle. If the acoustic wave is traveling in a moving fluid, the fluid velocity will affect the frequency of the traveling wave, relative to a stationary sensor. This frequency shift changes the angle of diffraction, hence, fluid velocity can be determined from the diffraction angle. The CFS acoustic Bragg grating data test indicates that it is capable of accurately determining flow from 0 to 10 meters per second. The same sensor can be used in flow velocities exceeding 100 m/s. The POL module has successfully determined the onset of two-phase flow, and can distinguish vapor bubbles from debris.

Justak, John↗
NASA NTRS2010

Architecture-Based Unit Testing of the Flight Software Product Line

This paper presents an analysis of the unit testing approach developed and used by the Core Flight Software (CFS) product line team at the NASA GSFC. The goal of the analysis is to understand, review, and reconunend strategies for improving the existing unit testing infrastructure as well as to capture lessons learned and best practices that can be used by other product line teams for their unit testing. The CFS unit testing framework is designed and implemented as a set of variation points, and thus testing support is built into the product line architecture. The analysis found that the CFS unit testing approach has many practical and good solutions that are worth considering when deciding how to design the testing architecture for a product line, which are documented in this paper along with some suggested innprovennents.

Ganesan, Dharmalingam↗
NASA NTRS2014

Assessment of NASA GISS CMIP5 and Post-CMIP5 Simulated Clouds and TOA Radiation Budgets Using Satellite Observations. Part I: Cloud Fraction and Properties

Although many improvements have been made in phase 5 of the Coupled Model Intercomparison Project (CMIP5), clouds remain a significant source of uncertainty in general circulation models (GCMs) because their structural and optical properties are strongly dependent upon interactions between aerosol/cloud microphysics and dynamics that are unresolved in such models. Recent changes to the planetary boundary layer (PBL) turbulence and moist convection parameterizations in the NASA GISS Model E2 atmospheric GCM(post-CMIP5, hereafter P5) have improved cloud simulations significantly compared to its CMIP5 (hereafter C5) predecessor. A study has been performed to evaluate these changes between the P5 and C5 versions of the GCM, both of which used prescribed sea surface temperatures. P5 and C5 simulated cloud fraction (CF), liquid water path (LWP), ice water path (IWP), cloud water path (CWP), precipitable water vapor (PWV), and relative humidity (RH) have been compared to multiple satellite observations including the Clouds and the Earth's Radiant Energy System-Moderate Resolution Imaging Spectroradiometer (CERES-MODIS, hereafter CM), CloudSat- Cloud-Aerosol Lidar and Infrared Pathfinder Satellite Observations (CALIPSO; hereafter CC), Atmospheric Infrared Sounder (AIRS), and Advanced Microwave Scanning Radiometer for Earth Observing System (AMSR-E). Although some improvements are observed in the P5 simulation on a global scale, large improvements have been found over the southern midlatitudes (SMLs), where correlations increased and both bias and root-mean-square error (RMSE) significantly decreased, in relation to the previous C5 simulation, when compared to observations. Changes to the PBL scheme have resulted in improved total column CFs, particularly over the SMLs where marine boundary layer (MBL) CFs have increased by nearly 20% relative to the previous C5 simulation. Globally, the P5 simulated CWPs are 25 gm22 lower than the previous C5 results. The P5 version of the GCM simulates PWV and RH higher than its C5 counterpart and agrees well with the AMSR-E and AIRS observations. The moister atmospheric conditions simulated by P5 are consistent with the CF comparison and provide a strong support for the increase in MBL clouds over the SMLs. Over the tropics, the P5 version of the GCM simulated total column CFs and CWPs are slightly lower than the previous C5 results, primarily as a result of the shallower tropical boundary layer in P5 relative to C5 in regions outside the marine stratocumulus decks.

General circulation models↗
NASA NTRS2017

Using CCSDS Standards to Reduce Mission Costs

NASA's open source Core Flight System (cFS) software framework has been using several Consultative Committee for Space Data Systems (CCSDS) standards since its inception. Recently developed CCSDS standards are now being applied by NASA, ESA and other organizations to streamline and automate aspects of mission development, test, and operations, speeding mission schedules and reducing mission costs. This paper will present the new CCSDS Spacecraft Onboard Interfaces Services (SOIS) Electronic Data Sheet (EDS) standards and show how they are being applied to data interfaces in the cFS software framework, tool chain, and ground systems across a range of missions at NASA. Although NASA is focusing on the cFS, it expected that these technologies are well suited for use in other system architectures and can lower costs for a wide range of both large and small satellites.

Wilmot, Jonathan↗
NASA NTRS2017

OpenSatKit Enables Quick Startup for CubeSat Missions

The software required to develop, integrate, and operate a spacecraft is substantial regardless of whether its a large or small satellite. Even getting started can be a monumental task. To solve this problem, NASAs Core Flight System (cFS), NASA's 42 spacecraft dynamics simulator, and Ball Aerospaces COSMOS ground system have been integrated together into a kit called OpenSatKit that provides a complete and open source software solution for starting a new satellite mission. Users can have a working system with flight software, dynamics simulation, and a ground command and control system up and running within hours.Every satellite mission requires three primary categories of software to function. The first is Flight Software (FSW) which provides the onboard control of the satellites and its payload(s). NASA's cFS provides a great platform for developing this software. Second, while developing a satellite on earth, it is necessary to simulate the satellites orbit, attitude, and actuators, to ensure that the systems that control these aspects will work correctly in the real environment. NASAs 42 simulator provides these functionalities. Finally, the ground has to be able to communicate with the satellite, monitor its performance and health, and display its data. Additionally, test scripts have to be written to verify the system on the ground. Ball Aerospace's COSMOS command and control system provides this functionality. Once the OpenSatKit is up and running, the next step is to customize the platform and get it running on the end target. Starting from a fully working system makes porting the cFS from Linux to a users platform much easier. An example Raspberry Pi target is included in the kit so users can gain experience working with a low cost hardware target. All users can benefit from OpenSatKit but the greatest impact and benefits will be to SmallSat missions with constrained budgets and small software teams. This paper describes OpenSatKits system design, the steps necessary to run the system to target the Raspberry Pi, and future plans. OpenSatKit is a free fully functional spacecraft software system that we hope will greatly benefit the SmallSat community.

Software↗
NASA NTRS2018

Plan Execution Interchange Language (PLEXIL) Software User's Manual

Plan Execution Interchange Language (PLEXIL) is a Core Flight System (or Core Flight Software) (cFS) based application, developed by the Autonomy Operating System project at NASA. cFS is open-source, reusable flight software, also developed by NASA and targeted to space missions. PLEXIL runs within the cFS framework, and is a wrapper integrating the open source PLEXIL Executive into the cFE (core Flight Executive) infrastructure. Software features include: Executes PLEXIL plans stored on local file system; Can be event-driven or clock-driven; and, Intended for "soft real time" discrete control.

Fry, Charles R.↗
NASA NTRSDate not supplied

TPSAS-NF1676L-11082-DND

Analysis of one decade of radar-lidar and Geostationary Operational Environmental Satellite (GOES) observations at the Atmospheric Radiation Measurement (ARM) Program Southern Great Plains (SGP) site reveals that there is excellent agreement in the long-term mean cloud fractions (CF) derived from the surface and GOES data, and the CF is independent of temporal resolution and spatial scales for grid boxes of size 0.5o to 2.5°. When computed over a 0.5-hr (4-hr) period, cloud frequency of occurrence (FREQ) and amount when present (AWP) derived from the point surface data agree very well with the same quantities determined from GOES for a 0.5o (2.5o) region centered on the ARM SGP site. The values of FREQ (AWP) derived from the radar-lidar observations at a given altitude increase (decrease) as the averaging period increases from 5 min to 6 hours. Similarly, CF at a given altitude increases as the vertical resolution increases from 90 to 1000 m. The profiles of CF have distinct bimodal vertical distributions with a lower peak between 1 and 2 km and a higher one between 8 and 11 km. The 10-year mean total CF, 46.9%, varies seasonally from a summer minimum of 39.8% to a maximum of 54.6% during the winter. The annual mean CF is 1-2% less than that from previous studies, ~48-49%, because fewer clouds occurred during 2005 and 2006, especially during winter. The differences in single- and multi-layered CFs between this study and an earlier analysis can be explained by the different temporal resolutions used in the two studies where single-layered CFs decrease but multilayered CFs increase from a 5-min resolution to a 1-hr resolution. The vertical distribution of nighttime GOES high-cloud tops agrees well with surface observations, but during daytime, fewer high clouds are retrieved by the GOES analysis than seen from the surface observations. The frequencies of occurrence for both daytime and nighttime GOES low-cloud tops are significantly higher than surface observations, but the cloud fractions are in good agreement.

B Xi↗
NASA NTRSDate not supplied

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↗
NASA NTRSDate not supplied

A new template for developing C++ applications in NASA's Core Flight System

In this presentation, we will demonstrate an example Core Flight System (cFS) application written in C++, compatible with the Draco releases of the Core Flight Executive (cFE) and NASA Operating System Abstraction Layer (OSAL). The application boilerplate, supporting library, and associated generation script were recently developed and licensed under the permissive Apache License 2.0 with the goal of easing the cFS app development with C++. The design and features of this application will be presented, including a higher-level interface for interactions with the cFE software bus pipes, tables, and event services. Data structures are provided for centralized telecommand and telemetry parsing which isolates bookkeeping of message components from the calling code in an application's core logic. Specific advantages of writing a cFS application in C++ will be shown, including easier avoidance of symbol collisions via namespaces, expanded compile-time checks via constant expressions, default initialization for data structures, null safety via references, improved syntax for operating on multi-dimensional arrays, and reliable serialization of enumerations via enumeration classes. Special considerations needed for integrating a C++ application will be identified, including function linkage, exceptions, and stack unwinding. Evidence for the usefulness of this template will be discussed in the context of development of a flight software application used for interfacing with a solid-state data recorder.

Dominick Allen↗
DOE OSTI2026

ARC disruption physics and strategy

Commonwealth Fusion Systems (CFS) plans to operate a tokamak power plant called ARC in the early 2030s. Tokamak plasmas have stability limits that, if crossed, lead to a rapid termination of the plasma, referred to as a disruption. Disruptions pose a melt risk to the first wall resulting from thermal and non-thermal particle heat fluxes, and an electromagnetic loading risk on all metal components within the equilibrium coils. A comprehensive set of models is used herein to provide an assessment of both mitigated and unmitigated ARC disruption loads. A preliminary massive gas injection system is baselined and a runaway electron mitigation coil option is proposed to close possible gaps in the baseline. It is predicted that all ARC disruption loads are within a factor of 2 of the disruption loads in SPARC, a tokamak presently under construction by CFS, and therefore SPARC provides an opportunity to calibrate models, test solutions and inform the design of ARC. The goal for ARC is disruption-free operation, however, the pragmatic design target is to withstand one mitigated disruption per day, and to restart the plasma following mitigation in tens of seconds without interrupting the power output. Unmitigated disruptions must be rare, and experience with unmitigated disruption impacts in SPARC will better define what rare means. The implications of this strategy for plasma disruptivity and disruption prediction are discussed, and operating the ARC scenario on SPARC is expected to refine the ARC final design and operational plan.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗