SEARCH · Engineering Papers

Results for “computational platforms and environments”

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 271 records · Page 15

All sources NASA NTRS DOE OSTI

NASA NTRS2021

Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment (CAPSTONE)

NASA has partnered with Advanced Space to develop and build the Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment (CAPSTONE) mission which will serve as a pathfinder for Near Rectilinear Halo Orbit (NHRO) operations around the Moon. The NHRO, (Perilune = 3,200 km; Apolune = 70,000 km) will be the intended orbit for the NASA’s Artemis Gateway lunar orbital platform. The CAPSTONE mission will validate simulations and confirm operational planning for Gateway while also validating performance of navigation and station-keeping requirements for the Power and Propulsion Element. Thus, this mission will provide operational experience to NASA, commercial, and international missions for operations in a demanding orbital regime. The baseline for CAPSTONE is to fly a 12U cubesat developed, integrated, and tested by Tyvak Nanosatellite Systems carrying a payload communications system capable of cross-link ranging with the Lunar Reconnaissance Orbiter (LRO), a dedicated payload flight computer for software demonstration, and a camera. The launch, coordinated by NASA Launch Services Program, will be provided by a Rocket Lab launch vehicle utilizing their new Proton upper stage to deploy the CAPSTONE spacecraft into the lunar orbit. The CAPSTONE mission is targeting a launch no earlier than September 23, 2021. Upon launch, the spacecraft will traverse a highly efficient transfer taking approximately three months to enter a primary demonstration phase in an NRHO for six months followed by a twelve month technology enhancement operations phase. The CAPSTONE Project is lead by Advanced Space, LLC of Boulder Colorado. Spacecraft development and mission operations will be conducted by Tyvak Nanosatellite Systems of Irvine, California. Noted objectives for the CAPSTONE mission will be to demonstrate the accessibility of NHROs, validate key operational concepts in the NHRO environment, lay a foundation for commercial support of future lunar operations and accelerate the availability of peer-to-peer navigation capabilities provided by the Cislunar Autonomous Positioning System (CAPS). The CAPSTONE mission is funded through NASA's Small Spacecraft Technology Program (SSTP), which is one of several programs in NASA’s Space Technology Mission Directorate. SSTP is chartered to develop and demonstrate technologies to enhance and expand the capabilities of small spacecraft with a particular focus on enabling new mission architectures through the use of small spacecraft, expanding the reach of small spacecraft to new destinations, and augmenting future missions with supporting small spacecraft. The launch for the CAPSTONE Mission is provided by Human Exploration & Operations Missions Directorate Advanced Exploration Systems Division. Coordination and Acquisition of the Launch is managed by NASA’s Launch Services Program. The CAPSTONE Mission and project status will be presented.

CAPSTONE↗

NASA NTRS2021

Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment (CAPSTONE) Mission

CAPSTONE↗

NASA NTRSDate not supplied

Dynamics of A Vibration Isolation System Including Inertia of the Human Body

Using an exercise device in a spacecraft is liable to transmit an unacceptable amount of vibration to that vehicle. This is commonly mitigated by a Vibration Isolation System (VIS), whose dynamics must be analyzed to confirm that the oscillatory forces on the spacecraft remain within allowed range, both from a structural and microgravity perspective (see, e.g., [1]). When modeling a VIS for countermeasures devices, one common approach is to record forces and moments applied on the floor while exercising, and then drive the VIS simulation by applying these recorded loads to the exercise platform part of the VIS mechanical model. This approach misses the fact that when exercising on a moving platform, the force and moment on it will differ from that on the stationary floor due to inertial effects involving the human body. For example, standing up on a platform as it gives under the subject’s feet reduces the foot force on it, and such inertial effects are especially complex for rotational motion. In principle, one could model both the motion of the human body and dynamics of the VIS mechanism in a single combined simulation, e.g., employing a tool such as the commonly used biomechanical simulation OpenSim. Here, the joints of the human body would be driven kinematically along prescribed exercise trajectories while the dynamics engine computed the response of the VIS degrees of freedom. However, mechanism designers and biomechanics experts have their own established tools, making it very desirable to have a way of decoupling the biomechanics from the VIS modeling, simulation, and analyses. We have derived a set of equations that rigorously accomplishes this goal, and have implemented them as an interface function that provides an alternative driving mechanism for an existing force-based VIS analysis simulation. When enabled, the simulated human/VIS system dynamics is now driven by this function, instead of the recorded force methodology described above. The function is designed to accept input from a data file containing the required time-stamped human motion and inertia terms corresponding to the specific exercise in question. This data file is generated by an OpenSim plugin written for that purpose. The existing VIS analytical simulation is developed using NASA’s Trick Simulation Environment [2], as well as its MBDyn multibody dynamics [3] package. The presentation will provide a detailed overview of the mathematical formulation, assumptions, plugin implementation, software interfaces, and results for a sample set of representative exercises. The results from this work aim to better inform VIS design efforts, as well as countermeasure device/protocol designs with respect to exercise type and frequency effects on vehicle structural and microgravity restrictions.

Countermeasures↗

NASA NTRS2011

InSAR Scientific Computing Environment

This computing environment is the next generation of geodetic image processing technology for repeat-pass Interferometric Synthetic Aperture (InSAR) sensors, identified by the community as a needed capability to provide flexibility and extensibility in reducing measurements from radar satellites and aircraft to new geophysical products. This software allows users of interferometric radar data the flexibility to process from Level 0 to Level 4 products using a variety of algorithms and for a range of available sensors. There are many radar satellites in orbit today delivering to the science community data of unprecedented quantity and quality, making possible large-scale studies in climate research, natural hazards, and the Earth's ecosystem. The proposed DESDynI mission, now under consideration by NASA for launch later in this decade, would provide time series and multiimage measurements that permit 4D models of Earth surface processes so that, for example, climate-induced changes over time would become apparent and quantifiable. This advanced data processing technology, applied to a global data set such as from the proposed DESDynI mission, enables a new class of analyses at time and spatial scales unavailable using current approaches. This software implements an accurate, extensible, and modular processing system designed to realize the full potential of InSAR data from future missions such as the proposed DESDynI, existing radar satellite data, as well as data from the NASA UAVSAR (Uninhabited Aerial Vehicle Synthetic Aperture Radar), and other airborne platforms. The processing approach has been re-thought in order to enable multi-scene analysis by adding new algorithms and data interfaces, to permit user-reconfigurable operation and extensibility, and to capitalize on codes already developed by NASA and the science community. The framework incorporates modern programming methods based on recent research, including object-oriented scripts controlling legacy and new codes, abstraction and generalization of the data model for efficient manipulation of objects among modules, and well-designed module interfaces suitable for command- line execution or GUI-programming. The framework is designed to allow users contributions to promote maximum utility and sophistication of the code, creating an open-source community that could extend the framework into the indefinite future.

Rosen, Paul A.↗

NASA NTRS2016

Trade-Space Analysis Tool for Constellations (TAT-C)

Traditionally, space missions have relied on relatively large and monolithic satellites, but in the past few years, under a changing technological and economic environment, including instrument and spacecraft miniaturization, scalable launchers, secondary launches as well as hosted payloads, there is growing interest in implementing future NASA missions as Distributed Spacecraft Missions (DSM). The objective of our project is to provide a framework that facilitates DSM Pre-Phase A investigations and optimizes DSM designs with respect to a-priori Science goals. In this first version of our Trade-space Analysis Tool for Constellations (TAT-C), we are investigating questions such as: How many spacecraft should be included in the constellation? Which design has the best costrisk value? The main goals of TAT-C are to: Handle multiple spacecraft sharing a mission objective, from SmallSats up through flagships, Explore the variables trade space for pre-defined science, cost and risk goals, and pre-defined metrics Optimize cost and performance across multiple instruments and platforms vs. one at a time.This paper describes the overall architecture of TAT-C including: a User Interface (UI) interacting with multiple users - scientists, missions designers or program managers; an Executive Driver gathering requirements from UI, then formulating Trade-space Search Requests for the Trade-space Search Iterator first with inputs from the Knowledge Base, then, in collaboration with the Orbit Coverage, Reduction Metrics, and Cost Risk modules, generating multiple potential architectures and their associated characteristics. TAT-C leverages the use of the Goddard Mission Analysis Tool (GMAT) to compute coverage and ancillary data, streamlining the computations by modeling orbits in a way that balances accuracy and performance.TAT-C current version includes uniform Walker constellations as well as Ad-Hoc constellations, and its cost model represents an aggregate model consisting of Cost Estimating Relationships (CERs) from widely accepted models. The Knowledge Base supports both analysis and exploration, and the current GUI prototype automatically generates graphics representing metrics such as average revisit time or coverage as a function of cost.

Science Data Processing↗

NASA NTRS1997

Of red planets and indigo computers: Mars database visualization as an example of platform downsizing

The last decade has witnessed tremendous advancements in the computer hardware and software used to perform scientific visualization. In this paper, we consider how the visualization of a particular data set, the digital terrain model derived from the Viking orbiter imagery, has been realized in four distinct projects over this period. These examples serve to demonstrate how the vast improvements in computational performance both decrease the cost of such visualization efforts and permit an increasing level of interactivity. We then consider how even today's graphical systems require the visualization designer to make intelligent choices and tradeoffs in database rendering. Finally, we discuss how insights gleaned from an understanding of human visual perception can guide these design decisions, and suggest new options for visualization hardware and software.

NASA Center ARC↗

NASA NTRS1983

Autonomy and the human element in space

NASA is contemplating the next logical step in the U.S. space program - the permanent presence of humans in space. As currently envisioned, the initial system, planned for the early 1990's, will consist of manned and unmanned platforms situated primarily in low Earth orbit. The manned component will most likely be inhabited by 6-8 crew members performing a variety of tasks such as materials processing, satellite servicing, and life science experiments. The station thus has utility in scientific and commercial enterprises, in national security, and in the development of advanced space technology. The technical foundations for this next step have been firmly established as a result of unmanned spacecraft missions to other planets, the Apollo program, and Skylab. With the shuttle, NASA inaugurates a new era of frequent flights and more routine space operations supporting a larger variety of missions. A permanently manned space system will enable NASA to expand the scope of its activities still further. Since NASA' s inception there has been an intense debate over the relative merits of manned and unmanned space systems. Despite the generally higher costs associated with manned components, astronauts have accomplished numerous essential, complex tasks in space. The unique human talent to evaluate and respond inventively to unanticipated events has been crucial in many missions, and the presence of crews has helped arouse and sustain public interest in the space program. On the other hand, the hostile orbital environment affects astronaut physiology and productivity, is dangerous, and mandates extensive support systems. Safety and cost factors require the entire station complex, both space and ground components, to be highly automated to free people from mundane operational chores. Recent advances in computer technology, artificial intelligence (AI), and robotics have the potential to greatly extend space station operations, offering lower costs and superior productivity. Extended operations can in turn enhance critical technologies and contribute to the competitive economic abilities of the United States. A high degree of automation and autonomy may be required to reduce dependence on ground systems, reduce mission costs, diminish complexity as perceived by the crew, increase mission lifetime and expand mission versatility. However, technologies dealing with heavily automated, long duration habitable spacecraft have not yet been thoroughly investigated by NASA. A highly automated station must amalgamate the diverse capabilities of people, machines, and computers to yield an efficient system which capitalizes on unique human characteristics. The station also must have an initial design which allows evolution to a larger and more sophisticated space presence. In the early years it is likely that AI-based subsystems will be used primarily in an advisory or planning capacity. As human confidence in automated systems grows and as technology advances, machines will take on more critical and interdependent roles. The question is whether, and how much, system autonomy will lead to improved station effectiveness.

Source record↗

NASA NTRS1993

Making tomorrow's mistakes today: Evolutionary prototyping for risk reduction and shorter development time

In the early days of JPL's solar system exploration, each spacecraft mission required its own dedicated data system with all software applications written in the mainframe's native assembly language. Although these early telemetry processing systems were a triumph of engineering in their day, since that time the computer industry has advanced to the point where it is now advantageous to replace these systems with more modern technology. The Space Flight Operations Center (SFOC) Prototype group was established in 1985 as a workstation and software laboratory. The charter of the lab was to determine if it was possible to construct a multimission telemetry processing system using commercial, off-the-shelf computers that communicated via networks. The staff of the lab mirrored that of a typical skunk works operation -- a small, multi-disciplinary team with a great deal of autonomy that could get complex tasks done quickly. In an effort to determine which approaches would be useful, the prototype group experimented with all types of operating systems, inter-process communication mechanisms, network protocols, packet size parameters. Out of that pioneering work came the confidence that a multi-mission telemetry processing system could be built using high-level languages running in a heterogeneous, networked workstation environment. Experience revealed that the operating systems on all nodes should be similar (i.e., all VMS or all PC-DOS or all UNIX), and that a unique Data Transport Subsystem tool needed to be built to address the incompatibilities of network standards, byte ordering, and socket buffering. The advantages of building a telemetry processing system based on emerging industry standards were numerous: by employing these standards, we would no longer be locked into a single vendor. When new technology came to market which offered ten times the performance at one eighth the cost, it would be possible to attach the new machine to the network, re-compile the application code, and run. In addition, we would no longer be plagued with lack of manufacturer support when we encountered obscure bugs. And maybe, hopefully, the eternal elusive goal of software portability across different vendors' platforms would finally be available. Some highlights of our prototyping efforts are described.

Friedman, Gary↗

NASA NTRS1997

Efficient Parallel Kernel Solvers for Computational Fluid Dynamics Applications

Distributed-memory parallel computers dominate today's parallel computing arena. These machines, such as Intel Paragon, IBM SP2, and Cray Origin2OO, have successfully delivered high performance computing power for solving some of the so-called "grand-challenge" problems. Despite initial success, parallel machines have not been widely accepted in production engineering environments due to the complexity of parallel programming. On a parallel computing system, a task has to be partitioned and distributed appropriately among processors to reduce communication cost and to attain load balance. More importantly, even with careful partitioning and mapping, the performance of an algorithm may still be unsatisfactory, since conventional sequential algorithms may be serial in nature and may not be implemented efficiently on parallel machines. In many cases, new algorithms have to be introduced to increase parallel performance. In order to achieve optimal performance, in addition to partitioning and mapping, a careful performance study should be conducted for a given application to find a good algorithm-machine combination. This process, however, is usually painful and elusive. The goal of this project is to design and develop efficient parallel algorithms for highly accurate Computational Fluid Dynamics (CFD) simulations and other engineering applications. The work plan is 1) developing highly accurate parallel numerical algorithms, 2) conduct preliminary testing to verify the effectiveness and potential of these algorithms, 3) incorporate newly developed algorithms into actual simulation packages. The work plan has well achieved. Two highly accurate, efficient Poisson solvers have been developed and tested based on two different approaches: (1) Adopting a mathematical geometry which has a better capacity to describe the fluid, (2) Using compact scheme to gain high order accuracy in numerical discretization. The previously developed Parallel Diagonal Dominant (PDD) algorithm and Reduced Parallel Diagonal Dominant (RPDD) algorithm have been carefully studied on different parallel platforms for different applications, and a NASA simulation code developed by Man M. Rai and his colleagues has been parallelized and implemented based on data dependency analysis. These achievements are addressed in detail in the paper.

Sun, Xian-He↗

NASA NTRS2014

Scalable Asset Discovery, Vulnerability Scanning, and Penetration Testing for Remote Sites and Wireless Spectrums Utilizing an Embedded Linux Plug - PwniPlug and the Raspberry Pi B+ as a Sample Pen Test

All devices attached to the NASA KSC network are subject to security vulnerability scanning and/or penetration testing. In today's changing environment, vulnerable and/or unprotected systems can easily be overlooked. Systems that are not properly managed can become a potential threat to the operational integrity of our systems and networks. This includes all NASA (internal and external) information systems within NASA KSC Internet Protocol (IP) address space, and NASA KSC facilities. The Office of the Chief Information Officer (OCIO) recommends that all NASA Centers and information systems be subject to penetration testing on a regular interval in accordance with the guidelines identified by the National Institute of Standards and Technology (NIST). (ITS-HBK-2810.04-02A) Protecting information and equipment at NASA is an area of increasing concern. In addition to the CPU's on the network; Supervisory, Control and Data Acquisition (SCADA) systems are especially vulnerable because these systems have lacked standards, use embedded controllers with little computational power and informal software, are connected to physical processes, have few operators, and are increasingly also being connected to corporate networks. The scope of work is comprised of several individual components which together build upon previous work by Drew Branch, NASA KSC Intern. The Pwn Plug is the selected COTS (Commercial-Off-The-Shelf) device chosen to test simplification of mandatory IT Security tasks. The device will be utilized to provide services to NASA KSC and enable an assessment of infrastructure soundness and regulatory compliance in an efficient, economical, and business responsive manner. The Pwn Plug is designed as a pen testing appliance which provides a hardware platform that can support commercial penetration testing efforts at significantly reduced costs. The expected outcomes are: 1) External Penetration Testing, 2) Social Engineering, 3) Procedural Documentation, 4) Recommended Remediation Action Plan, 5) System Retest & Remediation Attestation and 6) Final Reports, out briefing and Presentation. Due to physical and material constraints beyond intern and mentor control, the project was redefined as a working pen-test scenario. Limitations of lab availability and tools dictated an academic exercise. This report was developed within the scenario guidelines suggested by the project mentor. The guidelines were to be creative in developing a Pen Test program for a client.

Penetration Testing↗

NASA NTRS1994

Characterizing parallel file-access patterns on a large-scale multiprocessor

Rapid increases in the computational speeds of multiprocessors have not been matched by corresponding performance enhancements in the I/O subsystem. To satisfy the large and growing I/O requirements of some parallel scientific applications, we need parallel file systems that can provide high-bandwidth and high-volume data transfer between the I/O subsystem and thousands of processors. Design of such high-performance parallel file systems depends on a thorough grasp of the expected workload. So far there have been no comprehensive usage studies of multiprocessor file systems. Our CHARISMA project intends to fill this void. The first results from our study involve an iPSC/860 at NASA Ames. This paper presents results from a different platform, the CM-5 at the National Center for Supercomputing Applications. The CHARISMA studies are unique because we collect information about every individual read and write request and about the entire mix of applications running on the machines. The results of our trace analysis lead to recommendations for parallel file system design. First the file system should support efficient concurrent access to many files, and I/O requests from many jobs under varying load conditions. Second, it must efficiently manage large files kept open for long periods. Third, it should expect to see small requests predominantly sequential access patterns, application-wide synchronous access, no concurrent file-sharing between jobs appreciable byte and block sharing between processes within jobs, and strong interprocess locality. Finally, the trace data suggest that node-level write caches and collective I/O request interfaces may be useful in certain environments.

Purakayastha, Apratim↗

NASA NTRS2022

Design of Hypervelocity Flow Generator (HFG) and Its Diagnostics

Ground facilities for hypersonic research are a key element for successful development of aerodynamically proven hypervelocity vehicles. Design concepts and diagnostics of a hypervelocity flow generator (HFG) were made as a test platform for hypersonic/hypervelocity spacecraft models at the NASA Langley Research Center. The HFG is a hypersonic flow field generator using optically heated gas which is blown into an 80 cu m vacuum chamber. The vacuum chamber is kept at a stable vacuum pressure with a combination of three large vacuum pumps, while the HFG is in the test mode. The HFG provides a relatively small test section with approximately a 20 cm window. This facility was designed to generate 2.45 km/sec of flow speed, and potentially generate a continuous flow with the nozzle and vacuum system. The window in test section provides a direct view of the shock wave around a model in order to measure temperature, pressure, and density profile within the shock layer. One of the key test goals under this project is to understand why the emission spectra from the standing shockwave plasma predicted by Lora-Loran codes are significantly different from the measured emission spectra from the Flight Investigation Reentry Environment (FIRE II) Flight. The correct estimate of the thermal loading on the leading edge of hypersonic vehicles greatly affects the aerodynamic design, the material selection for the vehicle, and the cooling requirement and can be obtained by the precise modeling of emission spectra from shockwave plasma. However, the estimation of thermal loading is not an easy task due to complex non-equilibrium radiative process within high temperature shock layers that still falls into a category of cold plasma. Direct flight experiments are the most desirable, but not a cost-effective approach. Analysis by computational fluid dynamics (CFD) offers many test flexibilities. However, the CFD codes must be fully tested and validated with experimental data before the codes are effectively used for practical design. Large discrepancies between experiments and codes appear in hypersonic/hypervelocity flow regimes at high altitudes of 60 km ~ 90 km. This HFG facility offers some important parameters for CFD code validation, such as collision cross-sections, relaxation times, reaction rate coefficients and transportation coefficients. The HFG test facility is based on the ejection flow of high temperature gas heated over to 3500 K through a nozzle. The tungsten gas chamber of the HFG is heated up to a desired temperature by a 60 kW optical power beam source. This system consists of an optical power source, a thermal chamber, an expansion nozzle, a test section, and an 80 cu m vacuum tank. 60 kW optical input power is obtained from the 150 kW Vortek arc lamp system (by Vortek Industries, Vancouver, Canada). This optical beam is focused to heat the gas chamber within which a flow media is heated. The maximum achievable temperature of the flow medium reached approximately 3500 K or even higher but is limited by the melting point of the chamber material used. The exhaust velocity through the nozzle was determined by the stagnation temperature and the molecular weight of the working medium at the test section. To provide design parameters, a NASA Chemical Equilibrium with Application (CEA) computer program is used for the simulation of aerothermal data. This CEA program can calculate chemical equilibrium and properties of complex mixtures using shock tube parameters. For nitrogen gas at 2666 K stagnation temperature, the maximum achievable velocity at the test section is approximately 2.45 km/sec which is within the range of the thermal velocity of 8000 K shock layer. Based on the calculation through the CEA program, the design parameters of a HFG were determined and implemented for the test section that includes an expansion nozzle. The installed test section of the experimental facility can sustain a condition of a re-entry vehicle from the Space at an altitude of 60-90 km. After installation of the HFG, the system was fully tested and its operational parameters were measured. An 80 cu m vacuum chamber of HFG was set at 1 torr level to keep a stable downstream condition. The pumping time to reach the minimum vacuum pressure (~ 1 torr) at the test chamber from atmospheric pressure was approximately an hour using Kinney (MBV-14000/MB -1600/KT-300) and Stokes (Model 1772 and 412) pumps. Such a setup condition allowed a continued stable operation of the HFG experiment with flowrates through 1-, 3-, or 5-mm diameters of nozzle throat. The flow characteristics of the HFG for various operating conditions were performed using a focused Schlieren method. At 0.8 torr chamber pressure, a barrel shock was observed at the test section. With a sphere obstacle of 12 mm diameter in the flow, a bow shock (~ 2-mm thickness) was observed by a focused Schlieren visualization method.

Hypervelocity flow↗

NASA NTRS2013

FRET-Aptamer Assays for Bone Marker Assessment, C-Telopeptide, Creatinine, and Vitamin D

Astronauts lose 1.0 to 1.5% of their bone mass per month on long-duration spaceflights. NASA wishes to monitor the bone loss onboard spacecraft to develop nutritional and exercise countermeasures, and make adjustments during long space missions. On Earth, the same technology could be used to monitor osteoporosis and its therapy. Aptamers bind to targets against which they are developed, much like antibodies. However, aptamers do not require animal hosts or cell culture and are therefore easier, faster, and less expensive to produce. In addition, aptamers sometimes exhibit greater affinity and specificity vs. comparable antibodies. In this work, fluorescent dyes and quenchers were added to the aptamers to enable pushbutton, one-step, bind-and-detect fluorescence resonance energy transfer (FRET) assays or tests that can be freeze-dried, rehydrated with body fluids, and used to quantitate bone loss of vitamin D levels with a handheld fluorometer in the spacecraft environment. This work generated specific, rapid, one-step FRET assays for the bone loss marker C-telopeptide (CTx) when extracted from urine, creatinine from urine, and vitamin D congeners in diluted serum. The assays were quantified in nanograms/mL using a handheld fluorometer connected to a laptop computer to convert the raw fluorescence values into concentrations of each analyte according to linear standard curves. DNA aptamers were selected and amplified for several rounds against a 26- amino acid form of CTx, creatinine, and vitamin D. The commonalities between loop structures were studied, and several common loop structures were converted into aptamer beacons with a fluorophore and quencher on each end. In theory, when the aptamer beacon binds its cognate target (CTx bone peptide, creatinine, or vitamin D), it is forced open and no longer quenched, so it gives off fluorescent light (when excited) in proportion to the amount of target present in a sample. This proportional increase in fluorescence is called a "lights on" FRET response. The vitamin D aptamer beacon gives a "lights off" or inversely proportional fluorescence response to the amount of vitamin D present in diluted serum. These FRET-aptamer assays are rapid (<30 minutes), sensitive (low ng/mL detection limits), and quite easy to carry out (add sample, mix, and detect in the handheld reader). Benefits include the speed of the assays as well as the small amount of space taken up by the handheld reader and cuvette assays. The aptamer DNA sequences represent novel additional features of the existing (patent-pending) FRET-aptamer assay platform.

Bruno, John G.↗

NASA NTRSDate not supplied

New Tools for Automating Arcjet Sample Recession Tracking and Analysis

Arcjet Computer Vision (arcjetCV) has been significantly upgraded to enhance accuracy and performance in tracking material recession and shock-material standoff in test videos. These improvements include integrating new machine learning models, developing a specialized edge detection class, and incorporating a more comprehensive training dataset. These upgrades have refined the software’s ability to automate time-resolved recession tracking, making it more precise and reliable for analyzing complex physical processes. In parallel, a new tool called STARscan (Spatial Targeting and Alignment Rig for Scanning) is being developed to capture detailed 3D surface data before and after testing. By comparing these pre- and post-test scans with arcjetCV’s automated video analysis results, users can achieve a more comprehensive assessment of material recession. This method enables cross-validation of results, improving confidence in the analysis of tested materials. The expanded capabilities of arcjetCV have been successfully demonstrated on videos from various facilities, including the NASA Ames arcjets, UIUC’s PlasmatronX, and the VKI Plasmatron. It has been adopted as a new standard for in-situ recession tracking by the Mars Sample Return Project and Orion. ArcjetCV’s improved efficiency and accuracy are critical for reducing testing uncertainties and validating heatshield material performance under extreme conditions. The software’s user-friendly graphical interface ensures ease of use, enabling seamless processing and precise analysis of arcjet videos, providing deeper insights into material behavior in hypersonic environments. ArcjetCV is now available on both PyPI and Conda, allowing easy installation via "pip install arcjetCV" or through the Conda package manager, ensuring broad accessibility and streamlined deployment for users across various platforms.

Ablation↗

NASA NTRS1998

Developing Information Power Grid Based Algorithms and Software

This was an exploratory study to enhance our understanding of problems involved in developing large scale applications in a heterogeneous distributed environment. It is likely that the large scale applications of the future will be built by coupling specialized computational modules together. For example, efforts now exist to couple ocean and atmospheric prediction codes to simulate a more complete climate system. These two applications differ in many respects. They have different grids, the data is in different unit systems and the algorithms for inte,-rating in time are different. In addition the code for each application is likely to have been developed on different architectures and tend to have poor performance when run on an architecture for which the code was not designed, if it runs at all. Architectural differences may also induce differences in data representation which effect precision and convergence criteria as well as data transfer issues. In order to couple such dissimilar codes some form of translation must be present. This translation should be able to handle interpolation from one grid to another as well as construction of the correct data field in the correct units from available data. Even if a code is to be developed from scratch, a modular approach will likely be followed in that standard scientific packages will be used to do the more mundane tasks such as linear algebra or Fourier transform operations. This approach allows the developers to concentrate on their science rather than becoming experts in linear algebra or signal processing. Problems associated with this development approach include difficulties associated with data extraction and translation from one module to another, module performance on different nodal architectures, and others. In addition to these data and software issues there exists operational issues such as platform stability and resource management.

Dongarra, Jack↗

NASA NTRS2014

Collaborative WorkBench for Researchers - Work Smarter, Not Harder

It is important to define some commonly used terminology related to collaboration to facilitate clarity in later discussions. We define provisioning as infrastructure capabilities such as computation, storage, data, and tools provided by some agency or similarly trusted institution. Sharing is defined as the process of exchanging data, programs, and knowledge among individuals (often strangers) and groups. Collaboration is a specialized case of sharing. In collaboration, sharing with others (usually known colleagues) is done in pursuit of a common scientific goal or objective. Collaboration entails more dynamic and frequent interactions and can occur at different speeds. Synchronous collaboration occurs in real time such as editing a shared document on the fly, chatting, video conference, etc., and typically requires a peer-to-peer connection. Asynchronous collaboration is episodic in nature based on a push-pull model. Examples of asynchronous collaboration include email exchanges, blogging, repositories, etc. The purpose of a workbench is to provide a customizable framework for different applications. Since the workbench will be common to all the customized tools, it promotes building modular functionality that can be used and reused by multiple tools. The objective of our Collaborative Workbench (CWB) is thus to create such an open and extensible framework for the Earth Science community via a set of plug-ins. Our CWB is based on the Eclipse [2] Integrated Development Environment (IDE), which is designed as a small kernel containing a plug-in loader for hundreds of plug-ins. The kernel itself is an implementation of a known specification to provide an environment for the plug-ins to execute. This design enables modularity, where discrete chunks of functionality can be reused to build new applications. The minimal set of plug-ins necessary to create a client application is called the Eclipse Rich Client Platform (RCP) [3]; The Eclipse RCP also supports thousands of community-contributed plug-ins, making it a popular development platform for many diverse applications including the Science Activity Planner developed at JPL for the Mars rovers [4] and the scientific experiment tool Gumtree [5]. By leveraging the Eclipse RCP to provide an open, extensible framework, a CWB supports customizations via plug-ins to build rich user applications specific for Earth Science. More importantly, CWB plug-ins can be used by existing science tools built off Eclipse such as IDL or PyDev to provide seamless collaboration functionalities.

Ramachandran, Rahul↗

NASA NTRS2019

Orbital Debris Ontology, Terminology, and Knowledge Modeling

The looming threat orbital debris poses to assets in orbit demands solutions. As the orbital population grows, so does this hazard, but so does the sea of data. The problem is also an opportunity for interdisciplinary innovation and cooperation. This paper focuses on the data and information management aspect of developing solutions for a sustainable and safe orbital space environment. The corresponding author’s in-progress work to develop an orbital debris domain ontology is summarized in order to discuss knowledge modeling for this domain. Methodological approaches of this effort can also contribute to standards efforts and address terminological and policy questions. Leveraging the growing volumes of orbital debris and space situational awareness (SSA) data will create a more complete picture of the orbital space environment. Part of the solution will be: consistent and correct data interpretation, sharing orbital debris and SSA data in one form or another, terminology development & harmonization, and knowledge or domain modeling. To facilitate this, [Rovetto, 2015/16] discussed ontology development for the orbital debris domain. This paper lists concepts from that paper, and subsequently developed concepts [2-9]. Ontology engineering is an interdisciplinary field related to knowledge representation and reasoning in artificial intelligence, semantic technologies and the so-called semantic web. An ontology is effectively a computable and semantically rich terminology that presents a knowledge or domain model for a topic area. Expressions of knowledge or assertions are stored using formally defined term. This knowledge base is reasoned over to yield answers to queries, among other things. Ontologies have been developed in knowledge-based projects across various disciplines, and used for such things as search engines, chatbots, enterprise knowledge graphs, etc. Ontologies support: interoperability, automated reasoning, data sharing and integration, data search and retrieval, and communicating the meaning of data. The Orbital Debris Ontology (ODO), and related ontologies [Rovetto & Kelso 2016] [Rovetto 2016, 2017], were proposed to help achieve this. ODO, for instance, is intended as a domain ontology that can be used across federated databases, offering an explicitly specified set of concepts describing the orbital debris domain. Its meaning-rich taxonomy will provide a sharable semantics for orbital debris data to, in part, consistently communicate the meaning of data to both humans and machines, and tag data elements in space object catalogs to help afford inference tasks, decision support, knowledge discovery, and information integration. ODO and the SSA ontology (SSAO) is part of the overall Orbital Space Domain Ontology concept, which is conceived as a broader domain reference ontology. It aims to provide a knowledge representation structure of the orbital space environment, a common semantic model, and develop a sharable terminology. Collectively this will provide common meaning for datasets, a high-level taxonomy or classification for orbital space objects, and thus means to characterize space objects. Ongoing efforts have included using visualizations, R, JSON-LD, and contemporary semantic technologies. Potential applications and interdisciplinary partnerships include web-based platforms, web apps, visualizations, and academia projects. Community input and participation may yield a more widely understood domain model as well as facilitate terminological standards. For example, the proposed conceptual, terminological and ontological analysis may contribute to such efforts as the Space Debris Mitigation Requirements in the International Standards Organization by developing more precise, consistent and coherent terms and definitions. Projects that seek to develop in-house ontologies can use ODO and related ontologies as domain reference ontologies. This paper was developed independent of author affiliations. Readers are encouraged to contact corresponding author(1) with general interest and potential opportunities to support or realize the described project.

Robert J. Rovetto↗

NASA NTRS2008

Scripting Module for the Satellite Orbit Analysis Program (SOAP)

This add-on module to the SOAP software can perform changes to simulation objects based on the occurrence of specific conditions. This allows the software to encompass simulation response of scheduled or physical events. Users can manipulate objects in the simulation environment under programmatic control. Inputs to the scripting module are Actions, Conditions, and the Script. Actions are arbitrary modifications to constructs such as Platform Objects (i.e. satellites), Sensor Objects (representing instruments or communication links), or Analysis Objects (user-defined logical or numeric variables). Examples of actions include changes to a satellite orbit ( v), changing a sensor-pointing direction, and the manipulation of a numerical expression. Conditions represent the circumstances under which Actions are performed and can be couched in If-Then-Else logic, like performing v at specific times or adding to the spacecraft power only when it is being illuminated by the Sun. The SOAP script represents the entire set of conditions being considered over a specific time interval. The output of the scripting module is a series of events, which are changes to objects at specific times. As the SOAP simulation clock runs forward, the scheduled events are performed. If the user sets the clock back in time, the events within that interval are automatically undone. This script offers an interface for defining scripts where the user does not have to remember the vocabulary of various keywords. Actions can be captured by employing the same user interface that is used to define the objects themselves. Conditions can be set to invoke Actions by selecting them from pull-down lists. Users define the script by selecting from the pool of defined conditions. Many space systems have to react to arbitrary events that can occur from scheduling or from the environment. For example, an instrument may cease to draw power when the area that it is tasked to observe is not in view. The contingency of the planetary body blocking the line of sight is a condition upon which the power being drawn is set to zero. It remains at zero until the observation objective is again in view. Computing the total power drawn by the instrument over a period of days or weeks can now take such factors into consideration. What makes the architecture especially powerful is that the scripting module can look ahead and behind in simulation time, and this temporal versatility can be leveraged in displays such as x-y plots. For example, a plot of a satellite s altitude as a function of time can take changes to the orbit into account.

Carnright, Robert↗