Search NASA⌕ Search

SEARCH · Search NASA

Results for “Data Systems Engineers”

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 145 records · Page 8

Information Power Grid: Distributed High-Performance Computing and Large-Scale Data Management for Science and Engineering

We use the term "Grid" to refer to distributed, high performance computing and data handling infrastructure that incorporates geographically and organizationally dispersed, heterogeneous resources that are persistent and supported. This infrastructure includes: (1) Tools for constructing collaborative, application oriented Problem Solving Environments / Frameworks (the primary user interfaces for Grids); (2) Programming environments, tools, and services providing various approaches for building applications that use aggregated computing and storage resources, and federated data sources; (3) Comprehensive and consistent set of location independent tools and services for accessing and managing dynamic collections of widely distributed resources: heterogeneous computing systems, storage systems, real-time data sources and instruments, human collaborators, and communications systems; (4) Operational infrastructure including management tools for distributed systems and distributed resources, user services, accounting and auditing, strong and location independent user authentication and authorization, and overall system security services The vision for NASA's Information Power Grid - a computing and data Grid - is that it will provide significant new capabilities to scientists and engineers by facilitating routine construction of information based problem solving environments / frameworks. Such Grids will knit together widely distributed computing, data, instrument, and human resources into just-in-time systems that can address complex and large-scale computing and data analysis problems. Examples of these problems include: (1) Coupled, multidisciplinary simulations too large for single systems (e.g., multi-component NPSS turbomachine simulation); (2) Use of widely distributed, federated data archives (e.g., simultaneous access to metrological, topological, aircraft performance, and flight path scheduling databases supporting a National Air Space Simulation systems}; (3) Coupling large-scale computing and data systems to scientific and engineering instruments (e.g., realtime interaction with experiments through real-time data analysis and interpretation presented to the experimentalist in ways that allow direct interaction with the experiment (instead of just with instrument control); (5) Highly interactive, augmented reality and virtual reality remote collaborations (e.g., Ames / Boeing Remote Help Desk providing field maintenance use of coupled video and NDI to a remote, on-line airframe structures expert who uses this data to index into detailed design databases, and returns 3D internal aircraft geometry to the field); (5) Single computational problems too large for any single system (e.g. the rotocraft reference calculation). Grids also have the potential to provide pools of resources that could be called on in extraordinary / rapid response situations (such as disaster response) because they can provide common interfaces and access mechanisms, standardized management, and uniform user authentication and authorization, for large collections of distributed resources (whether or not they normally function in concert). IPG development and deployment is addressing requirements obtained by analyzing a number of different application areas, in particular from the NASA Aero-Space Technology Enterprise. This analysis has focussed primarily on two types of users: the scientist / design engineer whose primary interest is problem solving (e.g. determining wing aerodynamic characteristics in many different operating environments), and whose primary interface to IPG will be through various sorts of problem solving frameworks. The second type of user is the tool designer: the computational scientists who convert physics and mathematics into code that can simulate the physical world. These are the two primary users of IPG, and they have rather different requirements. The results of the analysis of the needs of these two types of users provides a broad set of requirements that gives rise to a general set of required capabilities. The IPG project is intended to address all of these requirements. In some cases the required computing technology exists, and in some cases it must be researched and developed. The project is using available technology to provide a prototype set of capabilities in a persistent distributed computing testbed. Beyond this, there are required capabilities that are not immediately available, and whose development spans the range from near-term engineering development (one to two years) to much longer term R&D (three to six years). Additional information is contained in the original.

Johnston, William E.↗

Command and Control System Automated Testing

The Kennedy Space Center (KSC) has developed its own Command and Control System for the launch of the Space Launch System (SLS) and Orion capsule. The Command and Control System (CCS) is used by console engineers for the launch and system checkout of aerospace vehicles. The CCS allows console engineers to read data from the flight hardware on the launch pad and from the ground control systems and allows console engineers to issue commands, like opening a valve, to the flight hardware and ground control systems. The CCS needs to interact with thousands of devices and hardware controllers for the spacecraft and ground systems, receive data from these devices, distribute the data to console engineers in real-time, and allow console engineers to issue commands to manipulate hardware on the launch pad. The system needs to be robust, fault tolerant, responsive, and fast. In order to keep up with the pace of development of the CCS, a Test Automation System (TAS) is needed to validate the integrity of the system as a whole along with its individual components. Automated tests allow for faster development time, since tests can be ran through a Continuous Integration system and allow developers to check their code faster. Currently, the different modules, classes, and functions that make up the CCS are tested at the unit level, and the system level, with all the modules working together. My project was to implement a system for the data protocol layer of the Command Control System to be tested as a complete functional unit, with all of its classes and functions working together, but independent of the other modules of the CCS.

Automated TestingTest Automation↗

Tuning a variational autoencoder for data accountability problem in the Mars Science Laboratory ground data system

The Mars Curiosity rover is frequently sending back engineering and science data that goes through a pipeline of systems before reaching its final destination at the mission operations center making it prone to volume loss and data corruption. A ground data system analysis (GDSA) team is charged with the monitoring of this flow of information and the detection of anomalies in that data in order to request a re-transmission when necessary. This work presents ∆-MADS, a derivative-free optimization method applied for tuning the architecture and hyperparameters of a variational autoencoder trained to detect the data with missing patches in order to assist the GDSA team in their mission.

Lakhmiri, Dounia↗

Engine systems analysis results of the Space Shuttle Main Engine redesigned powerhead initial engine level testing

Engineers regularly analyze SSME ground test and flight data with respect to engine systems performance. Recently, a redesigned SSME powerhead was introduced to engine-level testing in part to increase engine operational margins through optimization of the engine internal environment. This paper presents an overview of the MSFC personnel engine systems analysis results and conclusions reached from initial engine level testing of the redesigned powerhead, and further redesigns incorporated to eliminate accelerated main injector baffle and main combustion chamber hot gas wall degradation. The conclusions are drawn from instrumented engine ground test data and hardware integrity analysis reports and address initial engine test results with respect to the apparent design change effects on engine system and component operation.

Sander, Erik J.↗

Systems Engineering and Analysis in Support of a US Federal Staging Facility for UNF

The US Department of Energy Office of Nuclear Energy (DOE-NE) Office of Spent Fuel and High-Level Waste Disposition is examining a set of system options and conducting supporting analyses to inform the development of an integrated waste management system, which may include one or more federal staging facilities (FSFs) for used nuclear fuel (UNF ) sited using a collaborative siting process. This paper focuses on the ongoing activities in two systems engineering and analysis work areas: (1) data and tools development, validation, and maintenance and (2) systems engineering execution. Within the first work area, the STANDARDS 5.0 UNF data and analysis tool, formerly known as UNF-ST&DARDS, is being developed as a foundational resource to assist in the management of UNF data. It has the key capability to model UNF throughout the entire back end of the fuel cycle. STANDARDS also includes several compatible analysis tools for the time-dependent characterization of UNF and related systems by interfacing with the SCALE code system for nuclear analysis and COBRA-SFS for thermal analysis. Also, within the data and tools area is the Next Generation System Analysis Model (NGSAM), which is an agent-based simulation software tool expressly designed to be capable of modeling the waste management system, including the transportation of UNF to and from a FSF. NGSAM has been developed to enable informed decision-making by providing the capability to analyze various potential system options for the management of UNF and high-level radioactive waste. Finally, in the systems engineering execution area, the team has begun to apply a disciplined systems engineering approach at the system level along with supporting analysis to guide the development of the FSF project requirements (including associated transportation infrastructure). Systems engineering principles and practices and their adaptation/application to design and development activities will ensure that the waste management system is effectively implemented as work proceeds. Other activities include investigating the implications of changes in various assumptions and parameters related to waste management systems, such as UNF acceptance rates, receipt logic, facility capacities and capabilities, use of standardized canisters, and different assumed facility operation start dates. Keywords: federal staging facility (FSF), used nuclear fuel (UNF), integrated waste management (IWM) system, Next Generation System Analysis Model (NGSAM), STANDARDS, systems engineering

Joseph, Robert↗

Assessing Hot Fire Data with WinPlot

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health and performance pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

J. Davis Hunter↗

Outer atmospheric research

The region above the earth from about 90 km to 150 km is a major part of the upper or outer atmosphere. It is relatively unexplored, being too high for balloons or aircraft and too low for persistent orbiting spacecraft. However, the concept of a tethered subsatellite, deployed downward from an orbiting, more massive craft such as the Space Shuttle, opens the possibility of a research capability that could provide global mapping of this region. The need for research in this thick spherical shell above the earth falls into two major categories: (1) scientific data for understanding and modeling the global atmosphere and thereby determining its role in the earth system, and (2) engineering data for the design of future aerospace vehicles that will operate there. This paper presents an overview and synthesis of the currently perceived research needs and the state-of-the-art of the proposed tethered research capability.

Anderson, John L.↗

Orbit transfer rocket engine technology program: Automated preflight methods concept definition

The possibility of automating preflight engine checkouts on orbit transfer engines is discussed. The minimum requirements in terms of information and processing necessary to assess the engine'e integrity and readiness to perform its mission were first defined. A variety of ways for remotely obtaining that information were generated. The sophistication of these approaches varied from a simple preliminary power up, where the engine is fired up for the first time, to the most advanced approach where the sensor and operational history data system alone indicates engine integrity. The critical issues and benefits of these methods were identified, outlined, and prioritized. The technology readiness of each of these automated preflight methods were then rated on a NASA Office of Exploration scale used for comparing technology options for future mission choices. Finally, estimates were made of the remaining cost to advance the technology for each method to a level where the system validation models have been demonstrated in a simulated environment.

Erickson, C. M.↗

Third International Symposium on Space Mission Operations and Ground Data Systems, part 1

Under the theme of 'Opportunities in Ground Data Systems for High Efficiency Operations of Space Missions,' the SpaceOps '94 symposium included presentations of more than 150 technical papers spanning five topic areas: Mission Management, Operations, Data Management, System Development, and Systems Engineering. The papers focus on improvements in the efficiency, effectiveness, productivity, and quality of data acquisition, ground systems, and mission operations. New technology, techniques, methods, and human systems are discussed. Accomplishments are also reported in the application of information systems to improve data retrieval, reporting, and archiving; the management of human factors; the use of telescience and teleoperations; and the design and implementation of logistics support for mission operations.

Rash, James L.↗

RIM as the data base management system for a material properties data base

Relational Information Management (RIM) was selected as the data base management system for a prototype engineering materials data base. The data base provides a central repository for engineering material properties data, which facilitates their control. Numerous RIM capabilities are exploited to satisfy prototype data base requirements. Numerical, text, tabular, and graphical data and references are being stored for five material types. Data retrieval will be accomplished both interactively and through a FORTRAN interface. The experience gained in creating and exercising the prototype will be used in specifying requirements for a production system.

Karr, P. H.↗

Proof of Concept Study of Trade Space Configuration Tool for Spacecraft Design

Spacecraft design is a very difficult and time consuming process because requirements and criteria are often changed or modified as the design is refined. Accounting for these adjustments in the design constraints plays a significant role in furthering the overall progress. There are numerous aspects and variables that hold significant influence on various characteristics of the design. This can be especially frustrating when attempting to conduct rapid trade space analysis on system configurations. Currently, the data and designs considered for trade space evaluations can only be displayed by using the traditional interfaces of Excel spreadsheets or CAD (Computer Aided Design) models. While helpful, these methods of analyzing the data from a systems engineering approach can be rather complicated and overwhelming. As a result, a proof of concept was conducted on a dynamic data visualization software called Thinkmap SDK (Software Developer Kit) to allow for better organization and understanding of the relationships between the various aspects that make up an entire design. The Orion Crew Module Aft Bay Subsystem was used as the test case for this study because the design and layout of many of the subsystem components will be significant in ensuring the overall center of gravity of the capsule is correct. A simplified model of this subsystem was created and programmed using Thinkmap SDK to create a preliminary prototype application of a Trade Space Configuration Tool. The completed application ensures that the core requirements for the Tool can be met. Further development is strongly suggested to produce a full prototype application to allow final evaluations and recommendations of the software capabilities.

Glidden, Geoffrey L.↗

Assessing Engine Hot Fire Data for Human Spaceflight Applications

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

Data Assessment↗

Assessing Engine Hot Fire Data for Human Spaceflight Applications

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

Data Assessment↗

An Agile-Like Approach to Hardware Development: The Ejectable Data Recorder (EDR) for Orion's Ascent Abort 2 (AA-2) Test Flight

On July 2, 2019, the Ascent Abort 2 (AA-2) Flight Test Vehicle was launched from Cape Canaveral, with the goal of demonstrating the performance of Orion’s Launch Abort System (LAS) and collecting data from hundreds of sensors throughout the vehicle. The data collected during this test flight is of paramount importance, as it will be used to certify the Orion vehicle for human spaceflight. Originally, the data was to be downlinked via a single string network of antennas on the LAS, with the associated risk of potential data dropouts, as well as loss of data once the LAS was jettisoned. Thus, additional antennas were added onto the crew module (CM) to support data downlink post-LAS jettison, a buffer rebroadcast capability was added to fill in any gaps in data downlink transmissions, and an ejectable data recorder (EDR) subsystem was added to the CM as a redundant measure to collect all the instrumentation data. The EDR subsystem was added to the project about one year after the project commenced, which significantly reduced the available development time when compared with the other subsystems of the AA-2 Test Flight. The project was further accelerated by six months, around the critical design review gate. Due to the schedule compression challenge and the fact that the EDR subsystem was a backup system and not flight critical, the EDR subsystem was further challenged to find a new and more efficient way to develop hardware. Thus, the EDR subsystem experimented with different management and systems engineering processes, team sizes, communication methods, and tools. Some examples are novel uses of SharePoint as a Data-centric Project Management & Systems Engineering environment, a continuous testing approach through the lifecycle, and a Skunkworks approach to managing the team. The EDR subsystem blended Commercial Off The Shelf (COTS) hardware with in-house developed hardware and software to create a novel data retrieval capability. The capability evolved rapidly through a hardware in the loop simulation environment that enabled incremental component updates for not only the EDR subsystem but across the entire Crew Module. This paper will present an overview of how the EDR subsystem was managed and compare it to an Agile approach to managing projects. The paper will further provide a recommended approach to future Agile-like hardware development that incorporates lessons learned from the EDR experience.

Agile↗

Ground Data System Risk Mitigation Techniques for Faster, Better, Cheaper Missions

With the advent of faster, cheaper, and better missions, NASA Projects acknowledged that a higher level of risk was inherent and accepted with this approach. It was incumbent however upon each component of the Project whether spacecraft, payload, launch vehicle, or ground data system to ensure that the mission would nevertheless be an unqualified success. The Small Explorer (SMEX) program's ground data system (GDS) team developed risk mitigation techniques to achieve these goals starting in 1989. These techniques have evolved through the SMEX series of missions and are practiced today under the Triana program. These techniques are: (1) Mission Team Organization--empowerment of a closeknit ground data system team comprising system engineering, software engineering, testing, and flight operations personnel; (2) Common Spacecraft Test and Operational Control System--utilization of the pre-launch spacecraft integration system as the post-launch ground data system on-orbit command and control system; (3) Utilization of operations personnel in pre-launch testing--making the flight operations team an integrated member of the spacecraft testing activities at the beginning of the spacecraft fabrication phase; (4) Consolidated Test Team--combined system, mission readiness and operations testing to optimize test opportunities with the ground system and spacecraft; and (5). Reuse of Spacecraft, Systems and People--reuse of people, software and on-orbit spacecraft throughout the SMEX mission series. The SMEX ground system development approach for faster, cheaper, better missions has been very successful. This paper will discuss these risk management techniques in the areas of ground data system design, implementation, test, and operational readiness.

Catena, John J.↗

Dynamics and control characteristics of a reference Space Station configuration

This paper describes the structural dynamic characteristics of a NASA reference space station configuration as defined in the November 1987 Space Station Program - Systems Engineering and Integration Engineering Data Book. The modes and frequencies of the station below 2.0 Hz were obtained and selected results along with rigid body properties are presented. A three-axis attitude control system using control moment gyros responding to attitude and attitude rate signals is used to regulate the orientation of the station. The stability of the control system with non-collocated sensors is investigated for both compensated and uncompensated control signals. Results from a closed-loop simulation of a commanded attitude change about three axes, and from a closed-loop simulation of the response of the station to an externally applied unit force impulse at the docking port are presented. These simulation results are used to evaluate the possible degree of control/structures interaction which could occur during normal operation of the station.

Sutter, Thomas R.↗