Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Backward Compatibility”

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 37 records · Page 2

Representation-Independent Iteration of Sparse Data Arrays

An approach is defined that describes a method of iterating over massively large arrays containing sparse data using an approach that is implementation independent of how the contents of the sparse arrays are laid out in memory. What is unique and important here is the decoupling of the iteration over the sparse set of array elements from how they are internally represented in memory. This enables this approach to be backward compatible with existing schemes for representing sparse arrays as well as new approaches. What is novel here is a new approach for efficiently iterating over sparse arrays that is independent of the underlying memory layout representation of the array. A functional interface is defined for implementing sparse arrays in any modern programming language with a particular focus for the Chapel programming language. Examples are provided that show the translation of a loop that computes a matrix vector product into this representation for both the distributed and not-distributed cases. This work is directly applicable to NASA and its High Productivity Computing Systems (HPCS) program that JPL and our current program are engaged in. The goal of this program is to create powerful, scalable, and economically viable high-powered computer systems suitable for use in national security and industry by 2010. This is important to NASA for its computationally intensive requirements for analyzing and understanding the volumes of science data from our returned missions.

James, Mark↗

A Singular Perturbation Approach for Time-Domain Assessment of Phase Margin

This paper considers the problem of time-domain assessment of the Phase Margin (PM) of a Single Input Single Output (SISO) Linear Time-Invariant (LTI) system using a singular perturbation approach, where a SISO LTI fast loop system, whose phase lag increases monotonically with frequency, is introduced into the loop as a singular perturbation with a singular perturbation (time-scale separation) parameter Epsilon. First, a bijective relationship between the Singular Perturbation Margin (SPM) max and the PM of the nominal (slow) system is established with an approximation error on the order of Epsilon(exp 2). In proving this result, relationships between the singular perturbation parameter Epsilon, PM of the perturbed system, PM and SPM of the nominal system, and the (monotonically increasing) phase of the fast system are also revealed. These results make it possible to assess the PM of the nominal system in the time-domain for SISO LTI systems using the SPM with a standardized testing system called "PM-gauge," as demonstrated by examples. PM is a widely used stability margin for LTI control system design and certification. Unfortunately, it is not applicable to Linear Time-Varying (LTV) and Nonlinear Time-Varying (NLTV) systems. The approach developed here can be used to establish a theoretical as well as practical metric of stability margin for LTV and NLTV systems using a standardized SPM that is backward compatible with PM.

Zhu, J. Jim↗

A Comparison of Methods for Assessing Space Suit Joint Ranges of Motion

Through the Advanced Exploration Systems Program, NASA is attempting to use the vast collection of space suit mobility data from 50 years worth of space suit testing to build predictive analysis tools to aid in early architecture decisions for future missions and exploration programs. However, the design engineers must first understand if and how data generated by different methodologies can be compared directly and used in an essentially interchangeable manner. To address this question, the isolated joint range of motion data from two different test series were compared. Both data sets were generated from participants wearing the Mark III Space Suit Technology Demonstrator (MK-III), Waist Entry I-suit (WEI), and minimal clothing. Additionally the two tests shared a common test subject that allowed for within subject comparisons of the methods that greatly reduced the number of variables in play. The tests varied in their methodologies: the Space Suit Comparative Technologies Evaluation used 2D photogrammetry to analyze isolated ranges of motion while the Constellation space suit benchmarking and requirements development used 3D motion capture to evaluate both isolated and functional joint ranges of motion. The isolated data from both test series were compared graphically, as percent differences, and by simple statistical analysis. The results indicated that while the methods generate results that are statistically the same (significance level p= 0.01), the differences are significant enough in the practical sense to make direct comparisons ill advised. The concluding recommendations propose direction for how to bridge the data gaps and address future mobility data collection to allow for backward compatibility.

Aitchison, Lindsay↗

Recent Updates to the CFD General Notation System (CGNS)

The CFD General Notation System (CGNS) - a general, portable, and extensible standard for the storage and retrieval of computational fluid dynamics (CFD) analysis data has been in existence for more than a decade (Version 1.0 was released in May 1998). Both structured and unstructured CFD data are covered by the standard, and CGNS can be easily extended to cover any sort of data imaginable, while retaining backward compatibility with existing CGNS data files and software. Although originally designed for CFD, it is readily extendable to any field of computational analysis. In early 2011, CGNS Version 3.1 was released, which added significant capabilities. This paper describes these recent enhancements and highlights the continued usefulness of the CGNS methodology.

Rumsey, Christopher L.↗

A Comparison of Methods for Assessing Space Suit Joint Ranges of Motion

Through the Advanced Exploration Systems (AES) Program, NASA is attempting to use the vast collection of space suit mobility data from 50 years worth of space suit testing to build predictive analysis tools to aid in early architecture decisions for future missions and exploration programs. However, the design engineers must first understand if and how data generated by different methodologies can be compared directly and used in an essentially interchangeable manner. To address this question, the isolated joint range of motion data from two different test series were compared. Both data sets were generated from participants wearing the Mark III Space Suit Technology Demonstrator (MK-III), Waist Entry I-suit (WEI), and minimal clothing. Additionally the two tests shared a common test subject that allowed for within subject comparisons of the methods that greatly reduced the number of variables in play. The tests varied in their methodologies: the Space Suit Comparative Technologies Evaluation used 2-D photogrammetry to analyze isolated ranges of motion while the Constellation space suit benchmarking and requirements development used 3-D motion capture to evaluate both isolated and functional joint ranges of motion. The isolated data from both test series were compared graphically, as percent differences, and by simple statistical analysis. The results indicated that while the methods generate results that are statistically the same (significance level p= 0.01), the differences are significant enough in the practical sense to make direct comparisons ill advised. The concluding recommendations propose direction for how to bridge the data gaps and address future mobility data collection to allow for backward compatibility.

Aitchison, Lindsay T.↗

Regression Verification Using Impact Summaries

Regression verification techniques are used to prove equivalence of syntactically similar programs. Checking equivalence of large programs, however, can be computationally expensive. Existing regression verification techniques rely on abstraction and decomposition techniques to reduce the computational effort of checking equivalence of the entire program. These techniques are sound but not complete. In this work, we propose a novel approach to improve scalability of regression verification by classifying the program behaviors generated during symbolic execution as either impacted or unimpacted. Our technique uses a combination of static analysis and symbolic execution to generate summaries of impacted program behaviors. The impact summaries are then checked for equivalence using an o-the-shelf decision procedure. We prove that our approach is both sound and complete for sequential programs, with respect to the depth bound of symbolic execution. Our evaluation on a set of sequential C artifacts shows that reducing the size of the summaries can help reduce the cost of software equivalence checking. Various reduction, abstraction, and compositional techniques have been developed to help scale software verification techniques to industrial-sized systems. Although such techniques have greatly increased the size and complexity of systems that can be checked, analysis of large software systems remains costly. Regression analysis techniques, e.g., regression testing [16], regression model checking [22], and regression verification [19], restrict the scope of the analysis by leveraging the differences between program versions. These techniques are based on the idea that if code is checked early in development, then subsequent versions can be checked against a prior (checked) version, leveraging the results of the previous analysis to reduce analysis cost of the current version. Regression verification addresses the problem of proving equivalence of closely related program versions [19]. These techniques compare two programs with a large degree of syntactic similarity to prove that portions of one program version are equivalent to the other. Regression verification can be used for guaranteeing backward compatibility, and for showing behavioral equivalence in programs with syntactic differences, e.g., when a program is refactored to improve its performance, maintainability, or readability. Existing regression verification techniques leverage similarities between program versions by using abstraction and decomposition techniques to improve scalability of the analysis [10, 12, 19]. The abstractions and decomposition in the these techniques, e.g., summaries of unchanged code [12] or semantically equivalent methods [19], compute an over-approximation of the program behaviors. The equivalence checking results of these techniques are sound but not complete-they may characterize programs as not functionally equivalent when, in fact, they are equivalent. In this work we describe a novel approach that leverages the impact of the differences between two programs for scaling regression verification. We partition program behaviors of each version into (a) behaviors impacted by the changes and (b) behaviors not impacted (unimpacted) by the changes. Only the impacted program behaviors are used during equivalence checking. We then prove that checking equivalence of the impacted program behaviors is equivalent to checking equivalence of all program behaviors for a given depth bound. In this work we use symbolic execution to generate the program behaviors and leverage control- and data-dependence information to facilitate the partitioning of program behaviors. The impacted program behaviors are termed as impact summaries. The dependence analyses that facilitate the generation of the impact summaries, we believe, could be used in conjunction with other abstraction and decomposition based approaches, [10, 12], as a complementary reduction technique. An evaluation of our regression verification technique shows that our approach is capable of leveraging similarities between program versions to reduce the size of the queries and the time required to check for logical equivalence. The main contributions of this work are: - A regression verification technique to generate impact summaries that can be checked for functional equivalence using an off-the-shelf decision procedure. - A proof that our approach is sound and complete with respect to the depth bound of symbolic execution. - An implementation of our technique using the LLVMcompiler infrastructure, the klee Symbolic Virtual Machine [4], and a variety of Satisfiability Modulo Theory (SMT) solvers, e.g., STP [7] and Z3 [6]. - An empirical evaluation on a set of C artifacts which shows that the use of impact summaries can reduce the cost of regression verification.

Backes, John↗

SpaceCube Version 1.5

SpaceCube 1.5 is a high-performance and low-power system in a compact form factor. It is a hybrid processing system consisting of CPU (central processing unit), FPGA (field-programmable gate array), and DSP (digital signal processor) processing elements. The primary processing engine is the Virtex- 5 FX100T FPGA, which has two embedded processors. The SpaceCube 1.5 System was a bridge to the SpaceCube 2.0 and SpaceCube 2.0 Mini processing systems. The SpaceCube 1.5 system was the primary avionics in the successful SMART (Small Rocket/Spacecraft Technology) Sounding Rocket mission that was launched in the summer of 2011. For SMART and similar missions, an avionics processor is required that is reconfigurable, has high processing capability, has multi-gigabit interfaces, is low power, and comes in a rugged/compact form factor. The original SpaceCube 1.0 met a number of the criteria, but did not possess the multi-gigabit interfaces that were required and is a higher-cost system. The SpaceCube 1.5 was designed with those mission requirements in mind. The SpaceCube 1.5 features one Xilinx Virtex-5 FX100T FPGA and has excellent size, weight, and power characteristics [4×4×3 in. (approx. = 10×10×8 cm), 3 lb (approx. = 1.4 kg), and 5 to 15 W depending on the application]. The estimated computing power of the two PowerPC 440s in the Virtex-5 FPGA is 1100 DMIPS each. The SpaceCube 1.5 includes two Gigabit Ethernet (1 Gbps) interfaces as well as two SATA-I/II interfaces (1.5 to 3.0 Gbps) for recording to data drives. The SpaceCube 1.5 also features DDR2 SDRAM (double data rate synchronous dynamic random access memory); 4- Gbit Flash for storing application code for the CPU, FPGA, and DSP processing elements; and a Xilinx Platform Flash XL to store FPGA configuration files or application code. The system also incorporates a 12 bit analog to digital converter with the ability to read 32 discrete analog sensor inputs. The SpaceCube 1.5 design also has a built-in accelerometer. In addition, the system has 12 receive and transmit RS- 422 interfaces for legacy support. The SpaceCube 1.5 processor card represents the first NASA Goddard design in a compact form factor featuring the Xilinx Virtex- 5. The SpaceCube 1.5 incorporates backward compatibility with the Space- Cube 1.0 form factor and stackable architecture. It also makes use of low-cost commercial parts, but is designed for operation in harsh environments.

Geist, Alessandro↗

Optical Breath Gas Extravehicular Activity Sensor for the Advanced Portable Life Support System

The infrared gas transducer used during extravehicular activity (EVA) in the extravehicular mobility unit (EMU) measures and reports the concentration of carbon dioxide (CO2) in the ventilation loop. It is nearing its end of life and there are a limited number remaining. Meanwhile, the next generation advanced portable life support system (PLSS) now being developed requires CO2 sensing technology with performance beyond that presently in use. A laser diode (LD) spectrometer based on wavelength modulation spectroscopy (WMS) is being developed to address both applications by Vista Photonics, Inc. Accommodation within space suits demands that optical sensors meet stringent size, weight, and power requirements. Version 1.0 devices were delivered to NASA Johnson Space Center (JSC) in 2011. The sensors incorporate a laser diode based CO2 channel that also includes an incidental water vapor (humidity) measurement. The prototypes are controlled digitally with a field-programmable gate array (FPGA)/microcontroller architecture. Version 2.0 devices with improved electronics and significantly reduced wetted volumes were delivered to JSC in 2012. A version 2.5 upgrade recently implemented wavelength stabilized operation, better humidity measurement, and much faster data analysis/reporting. A wholly reconfigured version 3.0 will maintain the demonstrated performance of earlier versions while being backwards compatible with the EMU and offering a radiation tolerant architecture.

Wood, William R.↗

New Approaches for Direct Current (DC) Balanced SpaceWire

Direct Current (DC) line balanced SpaceWire is attractive for a number of reasons. Firstly, a DC line balanced interface provides the ability to isolate the physical layer with either a transformer or capacitor to achieve higher common mode voltage rejection and or the complete galvanic isolation in the case of a transformer. And secondly, it provides the possibility to reduce the number of conductors and transceivers in the classical SpaceWire interface by half by eliminating the Strobe line. Depending on the modulator scheme the clock data recovery frequency requirements may be only twice that of the transmit clock, or even match the transmit clock: depending on the Field Programmable Gate Array (FPGA) decoder design. In this paper, several different implementation scenarios will be discussed. Two of these scenarios are backward compatible with the existing SpaceWire hardware standards except for changes at the character level. Three other scenarios, while decreasing by half the standard SpaceWire hardware components, will require changes at both the character and signal levels and work with fixed rates. Other scenarios with variable data rates will require an additional SpaceWire interface handshake initialization sequence.

Line encoding↗

New Approaches for DC Balanced SpaceWire

Direct Current (DC) line balanced SpaceWire is attractive for a number of reasons. Firstly, a DC line balanced interface provides the ability to isolate the physical layer with either a transformer or capacitor to achieve higher common mode voltage rejection and/or the complete galvanic isolation in the case of a transformer. Secondly, it provides the possibility to reduce the number of conductors and transceivers in the classical SpaceWire interface by half by eliminating the Strobe line. Depending on the modulator scheme - the clock data recovery frequency requirements may be only twice that of the transmit clock, or even match the transmit clock: depending on the Field Programmable Gate Array (FPGA) decoder design. In this paper, several different implementation scenarios will be discussed. Two of these scenarios are backward compatible with the existing SpaceWire hardware standards except for changes at the character level. Three other scenarios, while decreasing by half the standard SpaceWire hardware components, will require changes at both the character and signal levels and work with fixed rates. Other scenarios with variable data rates will require an additional SpaceWire interface handshake initialization sequence.

SpaceWire↗

Optical Relay for Future NASA Geosynchronous Orbiting Satellite for High Data Rate Links to NASA User Missions

NASA is exploring options for its Next Generation Relay (NGR) architecture while the current Tracking Data Relay Satellite System (TDRSS) completes its mission. The plan is to start implementation of the NGR beginning around 2025. The new system of proposed relay satellites will greatly increase the data rates between low Earth orbiting (LEO) satellite missions and the NASA TDRSS relay satellites. This increase in data rates will allow an unprecedented increase in data throughput from the LEO satellite missions back to the principal investigators (PI). This can be accomplished at Ka-band frequencies with high order modulation or at optical frequencies using Differential Phase Shift Keying (DPSK). The first satellite in the next set of relay satellites will have to be backward compatible with current technology to support ongoing and planned missions. The new set of satellites will be launched over a 10-year period with design lifetimes of at least 15 years. To meet these requirements, we analyzed various architectures and designed both the communication payloads on the relay satellite and candidate payloads on the user spacecraft by utilizing optical heads already designed. From this analysis, a demonstration optical satellite named “the Next Generation Optical Relay Pathfinder” with Ka-band capabilities was proposed to be built and launched with the purpose of evaluating an integrated high-speed optical and Ka-band communication system. Given a cost limit for the demonstration satellite, various satellite configurations were developed by varying the number of optical communication payloads. The communication payload on the relay satellite consisted of three major sub-systems: 1) Optical communication payload, 2) Ka-band communication payload, 3) Digital processing and routing of signals. The size, mass (weight), and power (SWaP) of the communication payload and other sub-systems of the satellite were obtained. The NASA Glenn Research Center COMPASS team designed the Pathfinder satellite and performed a cost analysis for its build and launch. In this paper, we first describe the needs, drivers, and the associated challenges for the Next Generation Optical Relay Pathfinder to be capable of connecting multiple LEO and GEO satellites at high data rates. Second, we detail the concept of operations (ConOps) and the system architecture, including the satellite configurations considered, their attributes and limitations, and the size of the satellite needed for each configuration. Third, we provide a summary of the Next Generation Optical Relay Pathfinder satellite design trades and its key elements. Finally, we present the path needed for implementation and operations.

Warner, Joseph H. D.↗

The SPASE Data Model: A Metadata Standard for Registering, Finding, Accessing, and Using Heliophysics Data Obtained from Observations and Modeling

The Space Physics Archive Search and Extract Consortium has developed and implemented the SPASE Data Model that provides a common language for registering a wide range of Heliophysics data and other products. The Data Model enables discovery and access tools such that any researcher can obtain data easily, thereby facilitating research, including on space weather. The Data Model includes descriptions of Simulation Models and Numerical Output, pioneered by the Integrated Medium for Planetary Exploration (IMPEx) group in Europe, and subsequently adopted by the Community Coordinated Modeling Center (CCMC). The SPASE group intends to register all relevant Heliophysics data resources, including space-, ground-, and model-based. Substantial progress has been made, especially for space-based observational data and associated observatories, instruments, and display data. Legacy product registrations and access go back more than 50 years. Real-time data will be included. The National Aeronautics and Space Administration (NASA) portion of the SPASE group has funding that assures continuity in the upkeep of the Data Model and aids with adding new products. Tools are being developed for making and editing data descriptions. Digital Object Identifiers (DOIs) for Data Products can now be included in the descriptions. The data access that SPASE facilitates is becoming more uniform, and work is progressing on Web Service access via a standard Application Programming Interface. The SPASE Data Model is stable; changes over the past 9 years were additions of terms and capabilities that are backward compatible. This paper provides a summary of the history, structure, use, and future of the SPASE Data Model.

Roberts, D. Aaron↗

NEQAIR v15.0 Release Notes: Nonequilibrium and Equilibrium Radiative Transport and Spectra Program

NEQAIR v15.0 provides the first steps to improved coupling between NEQAIR and the DPLR CFD code, which will be fully realized in v15.1. The plan is to release NEQAIR v15.1 and DPLR 4.05 at the same time. The improvements implemented in NEQAIR v15.0 have focused on improving stability, solution robustness, usability and providing different options for running the code. It is also the first version of the code to have a new input file and line of sight format since 2009. Backward compatibility with previous formats of the input files (neqair.inp and LOS.dat) has also been provided. NEQAIR v15.0 supersedes the prerelease of this version, as well as NEQAIR v14.0, v13.2, v13.1 and the suite of NEQAIR2009 versions. These updates have predominantly been performed by Brett Cruden and Aaron Brandis from AMA Inc at NASA Ames Research Center between 2016 and 2018. NEQAIR v15.0 is a standalone software tool for line-by-line spectral computation of radiative intensities and/or radiative heat flux, with one-dimensional transport of radiation. In order to accomplish this, NEQAIR v15.0, as in previous versions, requires the specification of distances (in cm), temperatures (in K) and number densities (in parts/cc) of constituent species along lines of sight. Therefore, it is assumed that flow quantities have been extracted from flow fields computed using other tools, such as CFD codes like DPLR or LAURA, and that lines of sight have been constructed and written out in the format required by NEQAIR v15.0. There are two principal modes for running NEQAIR v15.0. In the first mode NEQAIR v15.0 is used as a tool for creating synthetic spectra of any desired resolution (including convolution with a specified instrument/slit function). The first mode is typically exercised in simulating/interpreting spectroscopic measurements of different sources (e.g. shock tube data, plasma torches, etc.). In the second mode, NEQAIR v15.0 is used as a radiative heat flux prediction tool for flight projects. Correspondingly, NEQAIR has also been used to simulate the radiance measured on previous flight missions. This report summarizes the database updates, corrections that have been made to the code, changes to input files, parallelization, the current usage recommendations, including test cases, and an indication of the performance enhancements achieved.

Brandis, Aaron M.↗

NASA Orbital Debris Engineering Model ORDEM 3.1 - Software User Guide

This National Aeronautics and Space Administration (NASA) Orbital Debris Engineering Model (ORDEM) 3.1 Software User Guide accompanies delivery of the latest upgraded version of the model, ORDEM 3.1. The user guide also provides a top-level program description and a list of capabilities. It includes descriptions of runtime error and information codes, input/output file formats, runtimes for different orbit configurations, and how to use uncertainty files. ORDEM 3.1 supersedes the previous NASA Orbital Debris Program Office (ODPO) models – ORDEM 3.0 (Stansbery, et al. 2014) and ORDEM2000 (Liou, et al. 2002). The availability of new sensor and in situ data, re-analysis of older data, and development of new analytical techniques has enabled the construction of this more comprehensive and sophisticated model. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. For example, these range from the conventional flux vs. average debris size (or altitude bin) for chosen analysis orbits (or views) to the more complex color-contoured, two-dimensional (2-D) directional flux diagrams in local spacecraft elevation and azimuth. The current model, ORDEM 3.1, supports spacecraft as well as telescope/radar project assessments. ORDEM 3.1 contains updated debris populations covering low Earth orbit (LEO, up to 2000 km altitude) to geosynchronous orbit (GEO, up to 40,000 km altitude) and can assess debris calculations up to year 2050, extending coverage past the previous limit of 2035 in ORDEM 3.0. Although populations differ from its predecessor, ORDEM 3.1 is functionally the same as ORDEM 3.0 and can support ORDEM 3.0 projects through backward compatibility.

Vavrin, Andrew B.↗

MEDPRAT Treatment Clusters: Improving Representation of Mission Medical Risk

INTRODUCTION The Medical Extensible Dynamic Probabilistic Risk Assessment Tool (MEDPRAT) implements a computational model that aims to quantify spaceflight medical risk by utilizing probabilistic techniques to simulate critical event incidence and outcomes over thousands of simulated mission trials. The goal of MEDPRAT is to characterize mission medical risk and provide insight into medical resource utilization. In order to analyze the medical resource space, treatment must be mapped from each simulated condition, and resources consumed as a result of this treatment must be tracked throughout the course of the mission. A new MEDPRAT feature, ‘treatment clusters’, provide a more sophisticated method of defining the structure and interaction between resources, more closely mimicking the way treatment is carried out clinically. METHODS Treatment clusters expand on the two existing treatment groupings (combination and alternate) adding a new grouping: bundled treatment. Treatment clusters may be combined to any depth, giving users the ability to specify complex treatment trees whose behavior is governed by several user-specified parameters. This approach emphasizes reusability, as treatment clusters, once defined, can be used to create more complex treatment trees or applied to many conditions. By configuring parameters for contribution, efficacy, necessity, primacy, and equivalence, resource relationships and dependencies can be more accurately represented, thereby allowing users to build capabilities with desired treatment properties, for example an intravenous capability for conditions such as anaphylaxis, acute radiation syndrome, etc. MEDPRAT v1.0 remains backward compatible with existing treatment structures, giving users the ability to define new treatment clusters as evidence becomes available, without having to recode their existing treatment databases. In addition to facilitating the representation of more complex treatment options, by pairing treatment clusters with the internal optimization routine, the MEDPRAT set selector, medical resources can be identified as organized in bundles, where appropriate, so that optimized resource sets include groups of highly-dependent resources only when all resources of the group are together. For example, it would be wasteful to include ultrasound gel but not an ultrasound machine, since the gel provides no benefit as a treatment without the ultrasound machine. With treatment clusters, the user may require that both resources are available to provide any benefit as treatment, so that if one resource is optimized out of the set, the other resource will be optimized out as well. RESULTS AND CONCLUSIONS We will report on MEDPRAT treatment clusters used in a bundling study under the IMPACT project of the ExMC element. We will discuss an example of a complex treatment tree. Through the implementation of this feature MEDPRAT enables treatment to be defined and applied in a way that is more representative of the real world, providing more accurate insight into mission medical risk and the medical resource space.

Lawrence Leinweber↗

Computing observation geometry for small satellites

Most solar system science missions need a variety of observation geometry–quantities such as position and velocity, range and altitude, viewing latitude and longitude, and lighting angles– to support mission engineering, science planning, and science data analysis activities. NASA's "SPICE" system offers one popular, multi-mission means for doing just that. SPICE comprises both data files, called kernels, and a SPICE software Toolkit that is available in many popular languages. A mission operations center produces the SPICE kernel files. Scientists and engineers write their own applications programs to address some need, and they include a few SPICE subroutines within that code to do the needed geometry computations. The SPICE system has been in use throughout NASA’s planetary science mission domain since 1991, and it has slowly spread to most major space agencies around the globe since then. The SPICE software is available in most popular languages, and for most popular platforms. The code is thoroughly tested before being released, and new versions of the Toolkit are always backwards compatible. The SPICE components are freely offered to everyone, and have no export, licensing or similar restrictions. Maybe using SPICE would work for your CubeSat or SmallSat mission?

Acton, Charles H.↗

NASA Orbital Debris Engineering Model ORDEM 3.2 – Software User Guide

This National Aeronautics and Space Administration (NASA) Orbital Debris Engineering Model (ORDEM) 3.2 Software User Guide accompanies delivery of the latest upgraded version of the model, ORDEM 3.2. The user guide also provides a top-level program description and a list of capabilities. It includes descriptions of runtime error and information codes, input/output file formats, runtimes for different orbit configurations, and how to use uncertainty files. ORDEM 3.2 supersedes the previous NASA Orbital Debris Program Office (ODPO) models – ORDEM 3.0 (Stansbery, et al. 2014) and ORDEM2000 (Liou, et al. 2002). The availability of new sensor and in situ data, re-analysis of older data, and development of new analytical techniques has enabled the construction of this more comprehensive and sophisticated model. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. For example, these range from the conventional flux vs. average debris size (or altitude bin) for chosen analysis orbits (or views) to the more complex color-contoured, two-dimensional (2-D) directional flux diagrams in local spacecraft elevation and azimuth. The current model, ORDEM 3.2, supports spacecraft as well as telescope/radar project assessments. ORDEM 3.2 contains updated debris populations covering low Earth orbit (LEO, up to 2000 km altitude) to geosynchronous orbit (GEO, up to 40,000 km altitude) and can assess debris calculations up to year 2050, extending coverage past the previous limit of 2035 in ORDEM 3.0. Although populations differ from its predecessor, ORDEM 3.2 is functionally the same as ORDEM 3.0 and can support ORDEM 3.0 projects through backward compatibility.

Andrew Vavrin↗

Updates and Modernization of NASA’s Chemical Equilibrium with Applications (CEA) Code

NASA’s Chemical Equilibrium with Applications (CEA) code is a foundational tool for propulsion system analysis. It provides equilibrium chemistry, rocket performance, shock, and detonation calculations used across NASA and the broader aerospace community. NASA Engineering and Safety Center (NESC) Activity TI-22-01730 modernized the legacy CEA2 Fortran code into CEA v3, a Fortran 2008, object-oriented software package with expanded interface support, updated thermochemical data, improved maintainability, and substantially improved workflow integration. The modernized code preserves backward compatibility with legacy CEA input workflows while enabling direct use from modern analysis environments, including Python, C, MATLAB, and automated design studies.

Mark K Leader↗