Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software infrastructure”

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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Developing a Vision for Heliophysics Infrastructure: The LIKED Resource and the DIARieS Ecosystem

Heliophysics data and computational infrastracture are not equipped for 21st science, suffering from holes in the know-how to build better systems. Without a clear vision, efforts to improve the infrastructure have been incremental and incoherent. This poster presents both the vision and the technology required: an online LIbrary KnowledgE and Discovery (LIKED) resource for discovering and implementing knowledge, data, and infrastructure resources; and an online analysis ecosystem to simplify Discovery, Implementation, Analysis, Reproducibility, and Sharing (DIARieS) of scientific results and environments. The LIKED and DIARieS solutions adopt FAIR data principles and the best practices from the budding field of open science. The proposed new infrastructure components will close many of the current gaps in heliophysics’ infrastructure, such as the ability to search for data and knowledge by phenomenon across domains, and to find software and examples relevant to the desired data set (including model data). Further, these components will enable community members to more efficiently use the resources already present and improve upon the content via a community-curated and trusted library. Combining these solutions lowers the barriers to heliophysics resources for all, increasing the return on our investments. Finally, the structure behind these ideas are topic-agnostic, so they are fully extensible to other fields, leading to invaluable connections to other disciplines. Just as with the development and construction of a long-term satellite mission, we must work together as a community to build a vision of the infrastructure that will most benefit the community, and then collaborate to construct, assemble, and test all the necessary pieces individually and as a unit. Our purpose in presenting this work is to not only describe the proposed vision, but also to gather feedback from the community on this topic.

infrastructure↗
NASA NTRSDate not supplied

Demonstrating the Promise and Problems for Open Science in Heliophysics

The recent push towards open science comes with a new set of problems to address. The additional work required to align a project with even the concepts of open science is at best problematic and typically not reasonably possible. The issue is further complicated by the lack of supporting infrastructure for the requirements of open science. We present the first executable paper in heliophysics as an example of how a collaboration between scientists, software developers, and software engineers can streamline the research process. This novel approach to science enables the science result to more easily adhere to the concepts of open science through the application of technology from inception to publication. We also use this paper to demonstrate gaps in our infrastructure that currently prevent progress in our pursuit of open science. This presentation is meant to initiate discussions of the methods and gaps presented, and we hope the discussion will be productive.

infrastructure↗
NASA NTRSDate not supplied

NASA Giovanni: Analyze, Compare, and Visualize 2000+ Earth Satellite and Model Variables Without Downloading Data and Software

Over vast oceans and remote continents, observations are often scarce and discontinuous. Satellite and model data play a critical role in research and applications. However, finding and accessing satellite and model data can be a daunting task for many, especially those outside the community. The NASA Goddard Earth Sciences (GES) Data and Information Services Center (DISC), one of 12 NASA Science Mission Directorate Data Centers, provides Earth science data, information, and services to everyone such as researchers, application users, educators, and students. GES DISC archives and supports datasets applicable to several NASA Earth Science Focus Areas including Atmospheric Composition, Water & Energy Cycles, Carbon Cycle & Ecosystem, and Climate Variability. To facilitate data discovery, evaluation, and exploration, GES DISC has developed the Geospatial Interactive Online Visualization ANd aNalysis Infrastructure (Giovanni), an online tool to analyze and visualize NASA remote sensing and model data without downloading data and software. As of this writing, over 2000 Earth satellite and model variables are available in Giovanni, including several wellknown NASA satellite missions (e.g., TRMM, GPM) and projects (e.g., MERRA-2, GPCP). Giovanni provides twenty-two plots that can be used to analyze, compare, and explore Earth data across different disciplines. Results can be shared with colleagues and downloaded for further analysis. Over the years, Giovanni has helped publish over 3000 referral papers. In this presentation, we will showcase key variables and plot types in Giovanni with examples. In particular, we will present several popular precipitation products from GPM and CPCP for evaluation and comparison.

data analysis↗
NASA NTRS2001

A Simple XML Producer-Consumer Protocol

There are many different projects from government, academia, and industry that provide services for delivering events in distributed environments. The problem with these event services is that they are not general enough to support all uses and they speak different protocols so that they cannot interoperate. We require such interoperability when we, for example, wish to analyze the performance of an application in a distributed environment. Such an analysis might require performance information from the application, computer systems, networks, and scientific instruments. In this work we propose and evaluate a standard XML-based protocol for the transmission of events in distributed systems. One recent trend in government and academic research is the development and deployment of computational grids. Computational grids are large-scale distributed systems that typically consist of high-performance compute, storage, and networking resources. Examples of such computational grids are the DOE Science Grid, the NASA Information Power Grid (IPG), and the NSF Partnerships for Advanced Computing Infrastructure (PACIs). The major effort to deploy these grids is in the area of developing the software services to allow users to execute applications on these large and diverse sets of resources. These services include security, execution of remote applications, managing remote data, access to information about resources and services, and so on. There are several toolkits for providing these services such as Globus, Legion, and Condor. As part of these efforts to develop computational grids, the Global Grid Forum is working to standardize the protocols and APIs used by various grid services. This standardization will allow interoperability between the client and server software of the toolkits that are providing the grid services. The goal of the Performance Working Group of the Grid Forum is to standardize protocols and representations related to the storage and distribution of performance data. These standard protocols and representations must support tasks such as profiling parallel applications, monitoring the status of computers and networks, and monitoring the performance of services provided by a computational grid. This paper describes a proposed protocol and data representation for the exchange of events in a distributed system. The protocol exchanges messages formatted in XML and it can be layered atop any low-level communication protocol such as TCP or UDP Further, we describe Java and C++ implementations of this protocol and discuss their performance. The next section will provide some further background information. Section 3 describes the main communication patterns of our protocol. Section 4 describes how we represent events and related information using XML. Section 5 describes our protocol and Section 6 discusses the performance of two implementations of the protocol. Finally, an appendix provides the XML Schema definition of our protocol and event information.

Smith, Warren↗
NASA NTRS2010

Kepler Science Operations Center Architecture

We give an overview of the operational concepts and architecture of the Kepler Science Data Pipeline. Designed, developed, operated, and maintained by the Science Operations Center (SOC) at NASA Ames Research Center, the Kepler Science Data Pipeline is central element of the Kepler Ground Data System. The SOC charter is to analyze stellar photometric data from the Kepler spacecraft and report results to the Kepler Science Office for further analysis. We describe how this is accomplished via the Kepler Science Data Pipeline, including the hardware infrastructure, scientific algorithms, and operational procedures. The SOC consists of an office at Ames Research Center, software development and operations departments, and a data center that hosts the computers required to perform data analysis. We discuss the high-performance, parallel computing software modules of the Kepler Science Data Pipeline that perform transit photometry, pixel-level calibration, systematic error-correction, attitude determination, stellar target management, and instrument characterization. We explain how data processing environments are divided to support operational processing and test needs. We explain the operational timelines for data processing and the data constructs that flow into the Kepler Science Data Pipeline.

Middour, Christopher↗
NASA NTRS1991

Search for supporting methodologies - Or how to support SEI for 35 years

Concepts relevant to the development of an evolvable information management system are examined in terms of support for the Space Exploration Initiative. The issues of interoperability within NASA and industry initiatives are studied including the Open Systems Interconnection standard and the operating system of the Open Software Foundation. The requirements of partitioning functionality into separate areas are determined with attention given to the infrastructure required to ensure system-wide compliance. The need for a decision-making context is a key to the distributed implementation of the program, and this environment is concluded to be next step in developing an evolvable, interoperable, and securable support network.

Handley, Thomas H., Jr.↗
NASA NTRS2003

Mission interactive scenarion studio for autonomous spacecraft

We propose building a Studio enabling the use of diverse existing mission activity and scenario patterns, the creation of new ones, and the modeling of their effects using existing modeling tools. The core of the Studio is a component-based Type Library, which captures years of mission adaptation patterns in various forms. The Studio works as a content server to capture the developed adaptation knowledge for reuse and provides bridging into different mission uplink implementations, including the Mission Data System [l] (MDS) state/goal machinery. Various activities can be coordinated, controlled, and reused through the Studio's component interface to establish and model a mission scenario. A special component Factory mechanism will be in place to facilitate the adaptation of projects into the Studio. The architecture of the Studio reflects and enforces a division of knowledge and actions into three parts: Model, Controller, Viewer. The Model contains information about (a proposed version of) the spacecraft and mission. The Controller contains logic for constructing scenarios of mission activities. The information in the Model and Controller is principally in the form of reusable patterns. A Viewer can be a simple or complex software system. For example, Apgen [2,3] is one possible viewer, MDS is another. A 3-tiered infrastructure is used for the Studio, reflecting the Model, Controller, Viewer architecture [4,5]. The Studio is useful in pre-phase A of a project by enabling spacecraft design options to be played against desired mission scenarios. In later design phases of a project, the construction and modeling of more detailed scenarios is supported by the Studio.

autonomous spacecraft↗
NASA NTRS2004

JPL Facilities and Software for Collaborative Design: 1994 - Present

The viewgraph presentation provides an overview of the history of the JPL Project Design Center (PDC) and, since 2000, the Center for Space Mission Architecture and Design (CSMAD). The discussion includes PDC objectives and scope; mission design metrics; distributed design; a software architecture timeline; facility design principles; optimized design for group work; CSMAD plan view, facility design, and infrastructure; and distributed collaboration tools.

project design center↗
NASA NTRS2009

Goddard Ground System Environment

This slide presentation reviews the Goddard Mission Services Evolution Center's work in providing the Ground System Infrastructure to allow for standard interfaces, and allow for a mix of heritage and new components. This software has been used by NASA and other Government users. Telemetry and command services are also provided as are mission planning and scheduling systems. Other areas that the presentation covers are work on trending systems, and data management system.

Liu, Ben↗
NASA NTRS2001

Development of a Space Radiation Monte-Carlo Computer Simulation Based on the FLUKE and Root Codes

The radiation environment in space is a complex problem to model. Trying to extrapolate the projections of that environment into all areas of the internal spacecraft geometry is even more daunting. With the support of our CERN colleagues, our research group in Houston is embarking on a project to develop a radiation transport tool that is tailored to the problem of taking the external radiation flux incident on any particular spacecraft and simulating the evolution of that flux through a geometrically accurate model of the spacecraft material. The output will be a prediction of the detailed nature of the resulting internal radiation environment within the spacecraft as well as its secondary albedo. Beyond doing the physics transport of the incident flux, the software tool we are developing will provide a self-contained stand-alone object-oriented analysis and visualization infrastructure. It will also include a graphical user interface and a set of input tools to facilitate the simulation of space missions in terms of nominal radiation models and mission trajectory profiles. The goal of this project is to produce a code that is considerably more accurate and user-friendly than existing Monte-Carlo-based tools for the evaluation of the space radiation environment. Furthermore, the code will be an essential complement to the currently existing analytic codes in the BRYNTRN/HZETRN family for the evaluation of radiation shielding. The code will be directly applicable to the simulation of environments in low earth orbit, on the lunar surface, on planetary surfaces (including the Earth) and in the interplanetary medium such as on a transit to Mars (and even in the interstellar medium). The software will include modules whose underlying physics base can continue to be enhanced and updated for physics content, as future data become available beyond the timeframe of the initial development now foreseen. This future maintenance will be available from the authors of FLUKA as part of their continuing efforts to support the users of the FLUKA code within the particle physics community. In keeping with the spirit of developing an evolving physics code, we are planning as part of this project, to participate in the efforts to validate the core FLUKA physics in ground-based accelerator test runs. The emphasis of these test runs will be the physics of greatest interest in the simulation of the space radiation environment. Such a tool will be of great value to planners, designers and operators of future space missions, as well as for the design of the vehicles and habitats to be used on such missions. It will also be of aid to future experiments of various kinds that may be affected at some level by the ambient radiation environment, or in the analysis of hybrid experiment designs that have been discussed for space-based astronomy and astrophysics. The tool will be of value to the Life Sciences personnel involved in the prediction and measurement of radiation doses experienced by the crewmembers on such missions. In addition, the tool will be of great use to the planners of experiments to measure and evaluate the space radiation environment itself. It can likewise be useful in the analysis of safe havens, hazard migration plans, and NASA's call for new research in composites and to NASA engineers modeling the radiation exposure of electronic circuits. This code will provide an important complimentary check on the predictions of analytic codes such as BRYNTRN/HZETRN that are presently used for many similar applications, and which have shortcomings that are more easily overcome with Monte Carlo type simulations. Finally, it is acknowledged that there are similar efforts based around the use of the GEANT4 Monte-Carlo transport code currently under development at CERN. It is our intention to make our software modular and sufficiently flexible to allow the parallel use of either FLUKA or GEANT4 as the physics transport engine.

Pinsky, L. S.↗
NASA NTRS2012

SCaN Testbed Software Development and Lessons Learned

National Aeronautics and Space Administration (NASA) has developed an on-orbit, adaptable, Software Defined Radio (SDR)Space Telecommunications Radio System (STRS)-based testbed facility to conduct a suite of experiments to advance technologies, reduce risk, and enable future mission capabilities on the International Space Station (ISS). The SCAN Testbed Project will provide NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking technologies in the laboratory and space environment based on reconfigurable, SDR platforms and the STRS Architecture.The SDRs are a new technology for NASA, and the support infrastructure they require is different from legacy, fixed function radios. SDRs offer the ability to reconfigure on-orbit communications by changing software for new waveforms and operating systems to enable new capabilities or fix any anomalies, which was not a previous option. They are not stand alone devices, but required a new approach to effectively control them and flow data. This requires extensive software to be developed to utilize the full potential of these reconfigurable platforms. The paper focuses on development, integration and testing as related to the avionics processor system, and the software required to command, control, monitor, and interact with the SDRs, as well as the other communication payload elements. An extensive effort was required to develop the flight software and meet the NASA requirements for software quality and safety. The flight avionics must be radiation tolerant, and these processors have limited capability in comparison to terrestrial counterparts. A big challenge was that there are three SDRs onboard, and interfacing with multiple SDRs simultaneously complicatesd the effort. The effort also includes ground software, which is a key element for both the command of the payload, and displaying data created by the payload. The verification of the software was an extensive effort. The challenges of specifying a suitable test matrix with reconfigurable systems that offer numerous configurations is highlighted. Since the flight system testing requires methodical, controlled testing that limits risk, a nearly identical ground system to the on-orbit flight system was required to develop the software and write verification procedures before it was installed and tested on the flight system. The development of the SCAN testbed was an accelerated effort to meet launch constraints, and this paper discusses tradeoffs made to balance needed software functionality and still maintain the schedule. Future upgrades are discussed that optimize the avionics and allow experimenters to utilize the SCAN testbed potential.

radio communication↗
NASA NTRS2014

The TSO Logic and G2 Software Product

This internship assignment for spring 2014 was at John F. Kennedy Space Center (KSC), in NASAs Engineering and Technology (NE) group in support of the Control and Data Systems Division (NE-C) within the Systems Hardware Engineering Branch. (NEC-4) The primary focus was in system integration and benchmarking utilizing two separate computer software products. The first half of this 2014 internship is spent in assisting NE-C4s Electronics and Embedded Systems Engineer, Kelvin Ruiz and fellow intern Scott Ditto with the evaluation of a newly piece of software, called G2. Its developed by the Gensym Corporation and introduced to the group as a tool used in monitoring launch environments. All fellow interns and employees of the G2 group have been working together in order to better understand the significance of the G2 application and how KSC can benefit from its capabilities. The second stage of this Spring project is to assist with an ongoing integration of a benchmarking tool, developed by a group of engineers from a Canadian based organization known as TSO Logic. Guided by NE-C4s Computer Engineer, Allen Villorin, NASA 2014 interns put forth great effort in helping to integrate TSOs software into the Spaceport Processing Systems Development Laboratory (SPSDL) for further testing and evaluating. The TSO Logic group claims that their software is designed for, monitoring and reducing energy consumption at in-house server farms and large data centers, allows data centers to control the power state of servers, without impacting availability or performance and without changes to infrastructure and the focus of the assignment is to test this theory. TSOs Aaron Rallo Founder and CEO, and Chris Tivel CTO, both came to KSC to assist with the installation of their software in the SPSDL laboratory. TSOs software is installed onto 24 individual workstations running three different operating systems. The workstations were divided into three groups of 8 with each group having its own operating system. The first group is comprised of Ubuntus Debian -based Linux the second group is windows 7 Professional and the third group ran Red Hat Linux. The highlight of this portion of the assignment is to compose documentation expressing the overall impression of the software and its capabilities.

TSO Logic↗
NASA NTRS1998

Satellite-Terrestrial Network Interoperability

The developing national and global information infrastructures (NII/GII) are being built upon the asynchronous transfer mode (ATM) telecommunications protocol and associated protocol standards. These protocols are themselves under development through the telecommunications standards process defined by the International Telecommunications Union (ITU), which as a body is sanctioned by the United Nations. All telecommunications manufacturers use these standards to create products that can interoperate. The ITU has recognized the ATM Forum as the instrument for the development of ATM protocols. This forum is a consortium of industry, academia, and government entities formed to quickly develop standards for the ATM infrastructure. However, because the participants represent a predominately terrestrial network viewpoint, the use of satellites in the national and global information infrastructures could be severely compromised. Consequently, through an ongoing task order, the NASA Lewis Research Center asked Sterling Software, Inc., to communicate with the ATM Forum in support of the interoperability of satellite-terrestrial networks. This year, Dr. Raj Jain of the Ohio State University, under contract to Sterling, authored or coauthored 32 explanatory documents delivered to the ATM Forum in the areas of Guaranteed Frame Rate for Transmission Control Protocol/Internet Protocol (TCP/IP), Available Bit Rate, performance testing, Variable Bit Rate voice over ATM, TCP over Unspecified Bit Rate+, Virtual Source/Virtual Destination, and network management. These contributions have had a significant impact on the content of the standards that the ATM Forum is developing. Some of the more significant accomplishments have been: (1) The adoption by the ATM Forum of a new definition for Message-In, Message-Out latency; and (2) Improved text (clearer wording and newly defined terms) for measurement procedures, foreground and background traffic, and scalable configuration in the latency and throughput sections of the Performance Testing Baseline Text.

vonDeak, Thomas C.↗
NASA NTRS2002

Summary report on the enterprise security workshop

This report summarizes the presentations of the 7th IEEE Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 2002) Enterprise Security (ES) Workshop.

software security cryptography authentication acce↗
NASA NTRS2011

Space Telecommunications Radio System (STRS) Compliance Testing

The Space Telecommunications Radio System (STRS) defines an open architecture for software defined radios. This document describes the testing methodology to aid in determining the degree of compliance to the STRS architecture. Non-compliances are reported to the software and hardware developers as well as the NASA project manager so that any non-compliances may be fixed or waivers issued. Since the software developers may be divided into those that provide the operating environment including the operating system and STRS infrastructure (OE) and those that supply the waveform applications, the tests are divided accordingly. The static tests are also divided by the availability of an automated tool that determines whether the source code and configuration files contain the appropriate items. Thus, there are six separate step-by-step test procedures described as well as the corresponding requirements that they test. The six types of STRS compliance tests are: STRS application automated testing, STRS infrastructure automated testing, STRS infrastructure testing by compiling WFCCN with the infrastructure, STRS configuration file testing, STRS application manual code testing, and STRS infrastructure manual code testing. Examples of the input and output of the scripts are shown in the appendices as well as more specific information about what to configure and test in WFCCN for non-compliance. In addition, each STRS requirement is listed and the type of testing briefly described. Attached is also a set of guidelines on what to look for in addition to the requirements to aid in the document review process.

Handler, Louis M.↗
NASA NTRS2002

Implementing Production Grids

We have presented the essence of experience gained in building two production Grids, and provided some of the global context for this work. As the reader might imagine, there were a lot of false starts, refinements to the approaches and to the software, and several substantial integration projects (SRB and Condor integrated with Globus) to get where we are today. However, the point of this paper is to try and make it substantially easier for others to get to the point where Information Power Grids (IPG) and the DOE Science Grids are today. This is what is needed in order to move us toward the vision of a common cyber infrastructure for science. The author would also like to remind the readers that this paper primarily represents the actual experiences that resulted from specific architectural and software choices during the design and implementation of these two Grids. The choices made were dictated by the criteria laid out in section 1. There is a lot more Grid software available today that there was four years ago, and various of these packages are being integrated into IPG and the DOE Grids. However, the foundation choices of Globus, SRB, and Condor would not be significantly different today than they were four years ago. Nonetheless, if the GGF is successful in its work - and we have every reason to believe that it will be - then in a few years we will see that the 28 functions provided by these packages will be defined in terms of protocols and MIS, and there will be several robust implementations available for each of the basic components, especially the Grid Common Services. The impact of the emerging Web Grid Services work is not yet clear. It will likely have a substantial impact on building higher level services, however it is the opinion of the author that this will in no way obviate the need for the Grid Common Services. These are the foundation of Grids, and the focus of almost all of the operational and persistent infrastructure aspects of Grids.

Johnston, William E.↗
NASA NTRS2003

Secured Advanced Federated Environment (SAFE): A NASA Solution for Secure Cross-Organization Collaboration

This paper discusses the challenges and security issues inherent in building complex cross-organizational collaborative projects and software systems within NASA. By applying the design principles of compartmentalization, organizational hierarchy and inter-organizational federation, the Secured Advanced Federated Environment (SAFE) is laying the foundation for a collaborative virtual infrastructure for the NASA community. A key element of SAFE is the Micro Security Domain (MSD) concept, which balances the need to collaborate and the need to enforce enterprise and local security rules. With the SAFE approach, security is an integral component of enterprise software and network design, not an afterthought.

Chow, Edward↗
NASA NTRS2005

Software-Reconfigurable Processors for Spacecraft

A report presents an overview of an architecture for a software-reconfigurable network data processor for a spacecraft engaged in scientific exploration. When executed on suitable electronic hardware, the software performs the functions of a physical layer (in effect, acts as a software radio in that it performs modulation, demodulation, pulse-shaping, error correction, coding, and decoding), a data-link layer, a network layer, a transport layer, and application-layer processing of scientific data. The software-reconfigurable network processor is undergoing development to enable rapid prototyping and rapid implementation of communication, navigation, and scientific signal-processing functions; to provide a long-lived communication infrastructure; and to provide greatly improved scientific-instrumentation and scientific-data-processing functions by enabling science-driven in-flight reconfiguration of computing resources devoted to these functions. This development is an extension of terrestrial radio and network developments (e.g., in the cellular-telephone industry) implemented in software running on such hardware as field-programmable gate arrays, digital signal processors, traditional digital circuits, and mixed-signal application-specific integrated circuits (ASICs).

Farrington, Allen↗