Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “specifications standards”

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 55 records · Page 3

The quality assurance role in the Deep Space Network

The quality assurance section provides skilled personnel who perform the following functions: quality hardware engineering, quality software engineering, inspection and testing, and an independent assessment to quality, engineering and project requirements. The quality assurance section provides specifications, workmanship standards, process specifications and quality assurance procedures in support of DSN equipment. In addition, the quality assurance section reviews DSN engineering documents to ensure that appropriate and adequate quality provisions are included.

Sirpilla, R. L.↗

Distributed photovoltaic systems: Utility interface issues and their present status

Major technical issues involving the integration of distributed photovoltaics (PV) into electric utility systems are defined and their impacts are described quantitatively. An extensive literature search, interviews, and analysis yielded information about the work in progress and highlighted problem areas in which additional work and research are needed. The findings from the literature search were used to determine whether satisfactory solutions to the problems exist or whether satisfactory approaches to a solution are underway. It was discovered that very few standards, specifications, or guidelines currently exist that will aid industry in integrating PV into the utility system. Specific areas of concern identified are: (1) protection, (2) stability, (3) system unbalance, (4) voltage regulation and reactive power requirements, (5) harmonics, (6) utility operations, (7) safety, (8) metering, and (9) distribution system planning and design.

Hassan, M.↗

Status of SEMI's solar-grade substrate standards

A proposal for a standard specifications listing covering requirements for silicon wafers used in solar cell manufacturing is outlined. The specific contents of the general requirements specifications include: ordering information; dimensions and permissible variations; material and manufacture; physical parameters; sampling; test methods; certification; and packaging and marking.

Gallagher, B. D.↗

The design and application of nickel-cadmium batteries in space

This paper describes the considerations given to selection of 20 and 50 A h nickel-cadmium cells and batteries for NASA/Goddard's Solar Max and Landsat D missions. Results of cell and battery manufacturer testing and improvements in design required by NASA standard specifications are shown. Operation of three batteries in parallel using a single voltage limit/current taper charge control system is described along with suggestions for optimizing life and uniformity. The results of three years of in-orbit operation is presented.

Halpert, G.↗

Water quality program elements for Space Station Freedom

A strategy is outlined for the development of water-quality criteria and standards relevant to recycling and monitoring the in-flight water for the Space Station Freedom (SSF). The water-reclamation subsystem of the SSF's ECLSS is described, and the objectives of the water-quality are set forth with attention to contaminants. Quality parameters are listed for potable and hygiene-related water including physical and organic parameters, inorganic constituents, bactericides, and microbial content. Comparisons are made to the quality parameters established for the Shuttle's potable water and to the EPA's current standards. Specific research is required to develop in-flight monitoring techniques for unique SSF contaminants, ECLSS microbial control, and on- and off-line monitoring. After discussing some of the in-flight water-monitoring hardware it is concluded that water reclamation and recycling are necessary and feasible for the SSF.

Sauer, Richard L.↗

ISSLive!

The ISSLive! project is a JSC innovation award- winning, combined MOD/Education project to publish export control and PAO-approved ISS telemetry, and simplified and scrubbed crew timelines. The publication of this data will be real-time or near real time and will include links to the crew's social media feeds and existing streaming public video/audio feeds, via public-friendly website, mobile devices and tablet applications. Additionally, the project will offer interactive virtual 3D views of an ISS model based on real-time telemetry and a 3D virtual mission control center based on existing Front Room console positions in made for public displays. The ISSLive! project is MOD-managed and includes collaborations with subject-matter expertise from the ISS flight controllers regarding daily operations and planning, education program specialists from the JSC Office of Education, instructional designers, human computer interface experts, and software/hardware experts from MOD facility organization, and senior web designers. In support of the Agency s Strategic Goal #6 with respect to using the ISS National Laboratory for education activities, ISSLive! uses the Station itself as STEM education subject matter and provides data for STEM-based lessons plans using national standards. Specifically, ISSLive! supports and enables the National Laboratory Education (NLE) project to address the Agency s Strategic Goal #6. This goal mandates, sharing NASA with the public, educators, and students to provide opportunities to participate in our Mission, foster innovation .. ISSLive! satisfies the Agency s outcomes of Strategic Goal; that is, engages the public in NASA's missions by providing new pathways for participation (Outcome 6.3) and it informs, engages, and inspires the public by sharing NASA s missions, challenges, and results (Outcome 6.4). Additionally, ISSLive! enables MOD s support of JSC Outreach and NASA's Open Data and Open Government Initiatives. The audience for the ISSLive! website and its application(s) are: teachers, students, citizen scientists, and the general public who will be given new and interactive insights on how the ISS Operates.

Price, Jennifer B.↗

Workflow-Based Software Development Environment

The Software Developer's Assistant (SDA) helps software teams more efficiently and accurately conduct or execute software processes associated with NASA mission-critical software. SDA is a process enactment platform that guides software teams through project-specific standards, processes, and procedures. Software projects are decomposed into all of their required process steps or tasks, and each task is assigned to project personnel. SDA orchestrates the performance of work required to complete all process tasks in the correct sequence. The software then notifies team members when they may begin work on their assigned tasks and provides the tools, instructions, reference materials, and supportive artifacts that allow users to compliantly perform the work. A combination of technology components captures and enacts any software process use to support the software lifecycle. It creates an adaptive workflow environment that can be modified as needed. SDA achieves software process automation through a Business Process Management (BPM) approach to managing the software lifecycle for mission-critical projects. It contains five main parts: TieFlow (workflow engine), Business Rules (rules to alter process flow), Common Repository (storage for project artifacts, versions, history, schedules, etc.), SOA (interface to allow internal, GFE, or COTS tools integration), and the Web Portal Interface (collaborative web environment

Izygon, Michel E.↗

Complete Decoding and Reporting of Aviation Routine Weather Reports (METARs)

Aviation Routine Weather Report (METAR) provides surface weather information at and around observation stations, including airport terminals. These weather observations are used by pilots for flight planning and by air traffic service providers for managing departure and arrival flights. The METARs are also an important source of weather data for Air Traffic Management (ATM) analysts and researchers at NASA and elsewhere. These researchers use METAR to correlate severe weather events with local or national air traffic actions that restrict air traffic, as one example. A METAR is made up of multiple groups of coded text, each with a specific standard coding format. These groups of coded text are located in two sections of a report: Body and Remarks. The coded text groups in a U.S. METAR are intended to follow the coding standards set by National Oceanic and Atmospheric Administration (NOAA). However, manual data entry and edits made by a human report observer may result in coded text elements that do not follow the standards, especially in the Remarks section. And contrary to the standards, some significant weather observations are noted only in the Remarks section and not in the Body section of the reports. While human readers can infer the intended meaning of non-standard coding of weather conditions, doing so with a computer program is far more challenging. However such programmatic pre-processing is necessary to enable efficient and faster database query when researchers need to perform any significant historical weather analysis. Therefore, to support such analysis, a computer algorithm was developed to identify groups of coded text anywhere in a report and to perform subsequent decoding in software. The algorithm considers common deviations from the standards and data entry mistakes made by observers. The implemented software code was tested to decode 12 million reports and the decoding process was able to completely interpret 99.93 of the reports. This document presents the deviations from the standards and the decoding algorithm. Storing all decoded data in a database allows users to quickly query a large amount of data and to perform data mining on the data. Users can specify complex query criteria not only on date or airport but also on weather condition. This document also describes the design of a database schema for storing the decoded data, and a Data Warehouse web application that allows users to perform reporting and analysis on the decoded data. Finally, this document presents a case study correlating dust storms reported in METARs from the Phoenix International airport with Ground Stops issued by Air Route Traffic Control Centers (ATCSCC). Blowing widespread dust is one of the weather conditions when dust storm occurs. By querying the database, 294 METARs were found to report blowing widespread dust at the Phoenix airport and 41 of them reported such condition only in the Remarks section of the reports. When METAR is a data source for an ATM research, it is important to include weather conditions not only from the Body section but also from the Remarks section of METARs.

METAR Decoder/Parser↗

Next Generation Flight Displays Using HTML5

The Human Integrated Vehicles and Environments (HIVE) lab at Johnson Space Center (JSC) is focused on bringing together inter-disciplinary talent to design and integrate innovative human interface technologies for next generation manned spacecraft. As part of this objective, my summer internship project centered on an ongoing investigation in to building flight displays using the HTML5 standard. Specifically, the goals of my project were to build and demo "flight-like" crew and wearable displays as well as create a webserver for live systems being developed by the Advanced Exploration Systems (AES) program. In parallel to my project, a LabVIEW application, called a display server, was created by the HIVE that uses an XTCE (XML (Extensible Markup Language) Telemetry and Command Exchange) parser and CCSDS (Consultative Committee for Space Data System) space packet decoder to translate telemetry items sent by the CFS (Core Flight Software) over User Datagram Protocol (UDP). It was the webserver's job to receive these UDP messages and send them to the displays. To accomplish this functionality, I utilized Node.js and the accompanying Express framework. On the display side, I was responsible for creating the power system (AMPS) displays. I did this by using HTML5, CSS and JavaScript to create web pages that could update and change dynamically based on the data they received from the webserver. At this point, I have not started on the commanding, being able to send back to the CFS, portion of the displays but hope to have this functionality working by the completion of my internship. I also created a way to test the webserver's functionality without the display server by making a JavaScript application that read in a comma-separate values (CSV) file and converted it to XML which was then sent over UDP. One of the major requirements of my project was to build everything using as little preexisting code as possible, which I accomplished by only using a handful of JavaScript libraries. As a side project, I created a model of the HIVE lab and Building 29 using SketchUp. I obtained the floorplans of the building from the JSC Geographic Information Systems (GIS), which were computer-aided design (CAD) files, and imported them into SketchUp. I then took those floorplans and created a 3D model of the building from them. Working in conjunction with the Hybrid Reality lab in Building 32, the SketchUp model was imported into Unreal Engine for use with the HTC Vive. Using the Vive, I was able to interact with the model I created in virtual reality (VR). The purpose of this side project was to be able to visualize potential lab layouts and mockup designs as they are in development in order to finalize design decisions. Pending approval, the model that I created will be used in the Build-As-You-Test: Can Hybrid Reality Improve the SE/HSI Design Process project in the fall. Getting the opportunity to work at NASA has been one of the most memorable experiences of my life. Over the course of my internship, I improved my programming and web development abilities substantially. I will take all the skills and experiences I have had while at NASA back to school with me in the fall and hope to pursue a career in the aerospace industry after graduating in the spring.

Greenwood, Brian↗

A Modeling Pattern for Layered System Interfaces

Communications between systems is often initially represented at a single, high level of abstraction, a link between components. During design evolution it is usually necessary to elaborate the interface model, defining it from several different, related viewpoints and levels of abstraction. This paper presents a pattern to model such multi-layered interface architectures simply and efficiently, in a way that supports expression of technical complexity, interfaces and behavior, and analysis of complexity. Each viewpoint and layer of abstraction has its own properties and behaviors. System elements are logically connected both horizontally along the communication path, and vertically across the different layers of protocols. The performance of upper layers depends on the performance of lower layers, yet the implementation of lower layers is intentionally opaque to upper layers. Upper layers are hidden from lower layers except as sources and sinks of data. The system elements may not be linked directly at each horizontal layer but only via a communication path, and end-to-end communications may depend on intermediate components that are hidden from them, but may need to be shown in certain views and analyzed for certain purposes. This architectural model pattern uses methods described in ISO 42010, Recommended Practice for Architectural Description of Software-intensive Systems and CCSDS 311.0-M-1, Reference Architecture for Space Data Systems (RASDS). A set of useful viewpoints and views are presented, along with the associated modeling representations, stakeholders and concerns. These viewpoints, views, and concerns then inform the modeling pattern. This pattern permits viewing the system from several different perspectives and at different layers of abstraction. An external viewpoint treats the systems of interest as black boxes and focuses on the applications view, another view exposes the details of the connections and other components between the black boxes. An internal view focuses on the implementation within the systems of interest, either showing external interface bindings and specific standards that define the communication stack profile or at the level of internal behavior. Orthogonally, a horizontal view isolates a single layer and a vertical viewpoint shows all layers at a single interface point between the systems of interest. Each of these views can in turn be described from both behavioral and structural viewpoints.

Shames, Peter M.↗

Storage of Physical Sample Metadata in the Astrobiology Habitable Environments Database (AHED)

The National Aeronautics and Space Administration has begun an effort to store, curate, and publish information about physical samples collected and analyzed in conjunction with NASA-funded astrobiology research. Astrobiology is a multidisciplinary area of scientific research being conducted by collaborating teams of biologists, chemists, geologists, atmospheric scientists, oceanographers, astrophysicists, astronomers, and other specialists. Astrobiology studies the origin, evolution, and distribution of life in the Universe. NASA uses the results of astrobiology research to focus its future missions on targets of opportunity for the discovery of life off Earth. Astrobiology researchers conduct both field-based and laboratory-based research, during which physical samples are collected, processed, and catalogued. The cataloguing practices employed by different teams of astrobiologists vary widely, and there are no specific standards available to guide the collection and recording of astrobiology sample data. The disparity in data collection approaches and the lack of a centralized sample repository makes it difficult for astrobiology teams to share data and benefit from resultant synergies.To facilitate data sharing within the astrobiology community, NASA is developing a prototype database the Astrobiology Habitable Environments Database (AHED) and an associated set of data collection templates. The database will store information about samples, along with associated measurements and analyses, including information about biological cultures enriched or isolated from samples, and the results of analyses performed on the samples (e.g., via spectrography, microscopy, etc.). In addition, the system will store contextual information about field sites where samples were collected, the instruments or equipment used for analysis, and people and institutions involved in their collection. AHED is being implemented on top of Open Data Repository's Data Publisher [1], an open source software platform for the publication of scientific datasets. The data collection templates under development represent an initial attempt to propose a set of metadata for capture and storage within AHED. The design of these templates is being conducted by a consolidated group of astrobiologists from active research teams at NASA Ames Research Center, assisted by data science and software engineering specialists. These initial templates must be vetted with the broader astrobiology community through a defined process to ensure that they meet community needs. Each template captures a different type of data collection record. For each template, we are developing a list of fields to be captured, including a set of required entry fields, a set of recommended but optional fields, and a set of discretionary fields. A datatype selected from a variety of text and numeric types is specified for each field. Included is a 'choice' type that restricts user input to an enumerated list of values. Many of the fields and field values capture information of particular interest to the astrobiology community, and are intended to facilitate search and retrieval of relevant data across multiple datasets.

Keller, Rich↗

UAS Service Supplier Framework for Authentication and Authorization

The Unmanned Aircraft Systems (UAS) Traffic Management (UTM) Service Supplier (USS) Framework for Authentication and Authorization (UFAA) is the basis for secure and confident data exchanges between the Flight Information Management System (FIMS) and the USS Network and within the USS Network itself. UFAA is built upon the OAuth 2.0 approach to federated authorization, with details supplied by various Internet Engineering Task Force (IETF) Request for Comment documents (RFCs). Whenever possible, a specific standard is used to support a design decision within UFAA, and when an applicable standard is not found/used, the technical decision is explained as much as possible. This document describes UFAA in detail. It is intended to serve as a reference for other key UTM documents and should be useful to many UTM stakeholders. This is an informative document. The requirements stated or implied in this document will need to be fully vetted and reviewed by appropriate stakeholders before becoming operational. It is highly encouraged that in any design decisions for future applicable standards that are counter to or missing from the decisions presented herein be justified in that future standard.

UTM↗

Firbimatic Vacuum Degreaser Cleaning Study

The purpose of this cleaning study was to establish the baseline of contaminants that can be removed using the Firbimatic Multisolvent 50-volt vacuum degreaser using Kyzen’s Metalnox® M6386 Solvent on 2219 aluminum alloy panels. Four different cleaning methods were used with six known contaminants. For each contaminant, five panels were contaminated—one was kept as a control, and the remaining four were cleaned using the vacuum degreaser. All applicable NASA, company, laboratory, and test-specific standard test practices were followed. Pre- and post-test results and photographs can be found in the appendices.

Morris, B. D.↗

Assessment of Airframe Noise Reduction Technologies Based on EPNL from Flight Tests

The acoustic performance of various airframe noise reduction technologies – Adaptive Compliant Trailing Edge flap, main landing gear fairings, and gear cavity treatments – was determined, individually and in combination, using the Effective Perceived Noise Level metric. These noise measurements and calculations closely follow the Federal Aviation Administration aircraft noise certification standards, specifically for the approach noise measurement point. The flyover data correspond to pole-mounted, single-microphone measurements obtained during a series of flight tests, conducted under the NASA Flight Demonstrations and Capabilities project, that evaluated flap and landing gear noise reduction technologies. To minimize contributions from the propulsion system, the aircraft was flown along the approach path with engine thrust set at ground idle. Although contamination from engine, background, and secondary airframe noise sources partially masked the true performance of the tested technologies, the resulting acoustic data clearly showed substantial noise reductions relative to baseline levels. The acoustic benefits measured by the single microphones are consistent with previously reported trends in acoustic levels obtained from phased microphone array data.

Ravetta, Patricio A.↗

Stewardship Best Practices for Improved Discovery and Reuse of Heterogeneous and Cross-Disciplinary Earth System Data

Some of the Earth system data products such as those from NASA airborne and field investigations (a.k.a. campaigns), are highly heterogeneous and cross-disciplinary, making the data extremely challenging to manage. For example, airborne and field campaign measurements tend to be sporadic over a period of time, with large gaps. Data products generated are of various processing levels and utilized for a wide range of inter- and cross-disciplinary research and applications. Data and derived products have been historically stored in a variety of domain-specific standard (and some non-standard) formats and in various locations such as NASA Distributed Active Archive Centers (DAACs), NASA airborne science facilities, field archives, or even individual scientists’ computer hard drives. As a result, airborne and field campaign data products have often been managed and represented differently, making it onerous for data users to find, access, and utilize campaign data. Some difficulties in discovering and accessing the campaign data originate from the incomplete data product and contextual metadata that may contain details relevant to the campaign (e.g. campaign acronym and instrument deployment locations), but tend to lack other significant information needed to understand conditions surrounding the data. Such details can be burdensome to locate after the conclusion of a campaign. Utilizing consistent terminology, essential for improved discovery and reuse, is also challenging due to the variety of involved disciplines. To help address the aforementioned challenges faced by many repositories and data managers handling airborne and field data, this presentation will describe stewardship practices developed by the Airborne Data Management Group (ADMG) within the Interagency Implementation and Advanced Concepts Team (IMPACT) under the NASA’s Earth Science Data systems (ESDS) Program.

best practices↗

A Multi-Architecture Approach for Implicit Computational Fluid Dynamics on Unstructured Grids

High-performance computing (HPC) architectures are trending toward manycore paradigms such as graphics processing units (GPUs). Approximately half of the top 100 publicly disclosed supercomputers in the world utilize GPU accelerators for performance. This is in contrast to a decade ago, where there were only a few such machines in the top 100. It is not currently possible to compile and run legacy central processing unit (CPU) software efficiently on GPUs without significant refactoring. Though a number of frameworks offering performance portability exist, none offer a standardized specification that is supported by all major hardware vendors. Additionally, experiences show that obtaining a high percentage of peak performance often requires architecture-specific code. This work details a pragmatic multi-architecture computational fluid dynamics library focused on aerospace problems across the speed range from low subsonic to hypersonic flows involving thermochemical nonequilibrium. A thin abstraction layer above NVIDIA CUDA C++ is utilized, which enables primarily single-source software currently capable of running efficiently on multicore CPUs, NVIDIA GPUs, AMD GPUs, and Intel GPUs. Results on various problems of interest across the speed range are presented and performance is compared between various architectures.

GPU↗

A Multi-Architecture Approach for Implicit Computational Fluid Dynamics on Unstructured Grids

High-performance computing (HPC) architectures are trending toward manycore paradigms such as graphics processing units (GPUs). Approximately half of the top 100 publicly disclosed supercomputers in the world utilize GPU accelerators for performance. This is in contrast to a decade ago, where there were only a few such machines in the top 100. It is not currently possible to compile and run legacy central processing unit (CPU) software efficiently on GPUs without significant refactoring. Though a number of frameworks offering performance portability exist, none offer a standardized specification that is supported by all major hardware vendors. Additionally, experiences show that obtaining a high percentage of peak performance often requires architecture-specific code. This work details a pragmatic multi-architecture computational fluid dynamics library focused on aerospace problems across the speed range from low subsonic to hypersonic flows involving thermochemical nonequilibrium. A thin abstraction layer above NVIDIA CUDA C++ is utilized, which enables primarily single-source software currently capable of running efficiently on multicore CPUs, NVIDIA GPUs, AMD GPUs, and Intel GPUs. Results on various problems of interest across the speed range are presented and performance is compared between various architectures.

GPU↗

Development of the Artemis Distributed Simulation FOMs

The National Aeronautics and Space Administration (NASA) is formulating and developing the Artemis Program, a collaboration with domestic commercial and international partners that will establish a long term human presence on the Moon and extend human exploration beyond the Earth-Moon system ahead of exploring Mars. These Artemis partners are developing a portfolio of space and surface systems to support human missions to the lunar surface and beyond. The Artemis systems will provide the mobility, habitation, and logistics infrastructure that will support human exploration and foster robust scientific investigations. Each partner will contribute one or more elements to the Artemis Program with NASA having the overarching responsibility for defining the Artemis architecture and guiding the integration of this complex system of space systems. To successfully accomplish this audacious task, NASA will rely on the development and execution of many complex models and simulations. Many of these simulations will be provided by the Artemis partners. While each of these simulations will provide important insight into the characteristics and performance of an associated system, individually they will not provide insight into the integrated performance of the architecture and the system of systems working in concert to execute a given Artemis mission. To address this need, NASA is developing a distributed simulation capability called the Artemis Distributed Simulation (ADS). ADS’s distributed nature supports the complex aggregation of constituent Artemis element simulations. Artemis partner simulations will be able to join into an ADS-based distributed simulation and interact with other Artemis element simulations while limiting the exposure of proprietary designs and data. ADS is defining a distributed simulation capability built on international simulation interoperability standards, specifically the High Level Architecture (HLA) and the Space Reference Federation Object Model (SpaceFOM). While HLA and SpaceFOM provide the substantive necessary technology basis for ADS, additional common datatypes, message definitions, and execution protocols are required. These extensions constitute the ADS Federation Object Model (FOM). This paper describes the fundamental architectural elements of ADS and the FOM extensions needed to support the complex nature of the Artemis Program. This includes the examination of the ADS FOM modules, ADS base datatypes, ADS SpaceFOM Object Class extensions, new ADS Object Classes, and new ADS Interaction Classes.

HLA↗