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.
Test control.
Environmental test control methods for improving quality and reducing costs, noting standardized specifications and information collection for administration
Tool simplifies machining of pipe ends for precision welding
Single tool prepares a pipe end for precision welding by simultaneously performing internal machining, end facing, and bevel cutting to specification standards. The machining operation requires only one milling adjustment, can be performed quickly, and produces the high quality pipe-end configurations required to ensure precision-welded joints.
The NASA program for standardizing silicon solar cells
The present work describes briefly the goals of the recently organized Standardized Space Power Systems Office and its program for developing low-cost, standard power system components for spacecraft. The first step is the development of standard specifications for solar cells and covers. These include: (1) physical dimensions, materials of construction, appearance and integrity of solar cell and coverglass; (2) electrical performance characteristics of solar cell and optical characteristics of coverglass; and (3) sampling, inspection, and electrical and environmental tests needed to demonstrate compliance with the above specifications.
Program design by a multidisciplinary team
The use of software engineering aids in the design of a structural finite-element analysis computer program for the STAR-100 computer is described. Nested functional diagrams to aid in communication among design team members were used, and a standardized specification format to describe modules designed by various members was adopted. This is a report of current work in which use of the functional diagrams provided continuity and helped resolve some of the problems arising in this long-running part-time project.
Electrically Conductive Paints for Satellites
A program was conducted to develop and test electrically conductive paint coatings for spacecraft. A wide variety of organic and inorganic coatings were formulated using conductive binders, conductive pigments, and similar approaches. Z-93, IITRI's standard specification inorganic thermal control coating, exhibits good electrical properties and is a very space-stable coating system. Several coatings based on a conductive pigment (antimony-doped tin oxide) in silicone and silicate binders offer considerable promise. Paint systems using commercially available conductive polymers also appear to be of interest, but will require substantial development. Evaluations were made based on electrical conductivity, paint physical properties, and the stability of spectral reflectance in space environment testing.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.