Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “library design”

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 289 records · Page 16

A new template for developing C++ applications in NASA's Core Flight System

In this presentation, we will demonstrate an example Core Flight System (cFS) application written in C++, compatible with the Draco releases of the Core Flight Executive (cFE) and NASA Operating System Abstraction Layer (OSAL). The application boilerplate, supporting library, and associated generation script were recently developed and licensed under the permissive Apache License 2.0 with the goal of easing the cFS app development with C++. The design and features of this application will be presented, including a higher-level interface for interactions with the cFE software bus pipes, tables, and event services. Data structures are provided for centralized telecommand and telemetry parsing which isolates bookkeeping of message components from the calling code in an application's core logic. Specific advantages of writing a cFS application in C++ will be shown, including easier avoidance of symbol collisions via namespaces, expanded compile-time checks via constant expressions, default initialization for data structures, null safety via references, improved syntax for operating on multi-dimensional arrays, and reliable serialization of enumerations via enumeration classes. Special considerations needed for integrating a C++ application will be identified, including function linkage, exceptions, and stack unwinding. Evidence for the usefulness of this template will be discussed in the context of development of a flight software application used for interfacing with a solid-state data recorder.

Dominick Allen↗

Artificial Intelligence (AI) Methods for Automating the Impact Tool Evidence Library

INTRODUCTION: The development of the Evidence Library for use with the IMPACT (Informing Mission Planning via Analysis of Complex Tradespaces) probability risk assessment tool involved a multilayered, time intensive process of data collection and analysis by subject matter experts from the Exploration Medical Capability (ExMC) Element Clinical and Science Team to produce clinical findings forms (CliFFs) for 120 medical conditions. Artificial Intelligence Large Language Models (LLMs) can be leveraged to facilitate this process, thus reducing labor and time. TOPIC: CliFFs contain information about medical conditions as they pertain to spaceflight. This includes condition definitions, incidence data, crew task impairment estimates caused by conditions, treatment protocols and references to literature used for gathering condition evidence. Guided by the Evidence Library Methods document and the CliFF development instructions, a team has leveraged Microsoft Azure AI services and open-source documentation to construct an AI-assisted automated pipeline for CliFF development. This process is designed to search, retrieve, and evaluate the applicable data, and ultimately generate a completed CliFF. The LLM evaluates the relevance of each of the source materials to spaceflight, either as direct evidence or as an analog. The model extracts keywords and generates brief summaries to enhance search and retrieval in later stages of CliFF development. For instance, it can calculate epidemiological statistical data, such as incidence rates and the likelihood of best or worst-case scenarios. APPLICATION: Large Language Models (LLMs) can efficiently summarize large amounts of text. Leveraging this technology will automate data retrieval and evidence gathering for medical databases, like the IMPACT tool, by aiding in the labor-intensive process of analyzing large bodies of literature and organizing it into a formatted document like a CliFF. This added efficiency will enable expeditious expansion of the Evidence Library with additional medical conditions and update previous CLiFFs as new technology becomes available.

Ali Al↗

JSC document index

The Johnson Space Center (JSC) document index is intended to provide a single source listing of all published JSC-numbered documents their authors, and the designated offices of prime responsibility (OPR's) by mail code at the time of publication. The index contains documents which have been received and processed by the JSC Technical Library as of January 13, 1988. Other JSC-numbered documents which are controlled but not available through the JSC Library are also listed.

Source record↗

Open-systems architecture of a standardized command interface chip-set for switching and control of a spacecraft power bus

The Jet Propulsion Laboratory (JPL) has developed a command interface chip-set that primarily consists of two mixed-signal ASICs'; the Command Interface ASIC (CIA) and Analog Interface ASIC (AIA). The Open-systems architecture employed during the design of this chip-set enables its use as both an intelligent gateway between the system's flight computer and the control, actuation, and activation of the spacecraft's loads, valves, and pyrotechnics respectfully as well as the regulator of the spacecraft power bus. Furthermore, the architecture is highly adaptable and employed fault-tolerant design methods enabling a host of other mission uses including reliable remote data collection. The objective of this design is to both provide a needed flight component that meets the stringent environmental requirements of current deep space missions and to add a new element to a growing library that can be used as a standard building block for future missions to the outer planets.

flight computers↗

Quality Assessment of Landsat Surface Reflectance Products Using MODIS Data

Surface reflectance adjusted for atmospheric effects is a primary input for land cover change detection and for developing many higher level surface geophysical parameters. With the development of automated atmospheric correction algorithms, it is now feasible to produce large quantities of surface reflectance products using Landsat images. Validation of these products requires in situ measurements, which either do not exist or are difficult to obtain for most Landsat images. The surface reflectance products derived using data acquired by the Moderate Resolution Imaging Spectroradiometer (MODIS), however, have been validated more comprehensively. Because the MODIS on the Terra platform and the Landsat 7 are only half an hour apart following the same orbit, and each of the 6 Landsat spectral bands overlaps with a MODIS band, good agreements between MODIS and Landsat surface reflectance values can be considered indicators of the reliability of the Landsat products, while disagreements may suggest potential quality problems that need to be further investigated. Here we develop a system called Landsat-MODIS Consistency Checking System (LMCCS). This system automatically matches Landsat data with MODIS observations acquired on the same date over the same locations and uses them to calculate a set of agreement metrics. To maximize its portability, Java and open-source libraries were used in developing this system, and object-oriented programming (OOP) principles were followed to make it more flexible for future expansion. As a highly automated system designed to run as a stand-alone package or as a component of other Landsat data processing systems, this system can be used to assess the quality of essentially every Landsat surface reflectance image where spatially and temporally matching MODIS data are available. The effectiveness of this system was demonstrated using it to assess preliminary surface reflectance products derived using the Global Land Survey (GLS) Landsat images for the 2000 epoch. As surface reflectance likely will be a standard product for future Landsat missions, the approach developed in this study can be adapted as an operational quality assessment system for those missions.

Landsat↗

The Psyche Planning Software Subsystem: Creating a Robust Toolset for a Discovery-class Mission

Psyche is a Discovery-class mission to the small metal-rich asteroid (16) Psyche, and is slated to launch in 2022. Psyche, like many missions, requires low-cost activity planning and sequence generation that serves as the backbone to overall uplink design. Such tools must be maintainable over long periods of operations, and powerful enough to solve complex issues that deep-space one-off missions encounter. In this paper we introduce cost-effective solutions that leverage inner- and open-source principles to meet a variety of common and novel use cases.The uplink process that was designed to meet these challenges is presented, as well as the data-flow through the high-level architecture of the planning software subsystem. The user-facing planning tools are described, particularly the Science Opportunity Analyzer, the Plan Editor, Psyche’s planning automation in the Blackbird framework, and Psyche Simulation Reports. All these applications are either new or have been substantially revamped to meet Psyche’s concept of operations. In particular, ensuring the entire toolchain can correctly process epoch-relative activities is discussed. Underlying the main applications are a common set of dependencies developed and maintained by a new cross-mission association of planning developers. In this way, Psyche can inherit well-tested functionality which saves effort and ensures its developers can focus on solving domain challenges. Quality control of the applications and libraries is ensured with a code-review and unit-test based novel ‘CM lite’ process. Collaboration with international industry and academia using the open-source modules is already occurring.The planning and scheduling software is designed to maximize operator awareness of the integrated plan at every step of the process and use common interfaces and file formats to easily transfer information. Design choices plus the team’s test-driven development process enables more expansive capabilities compared to the decentralized planning and sequence generation functions typical of Discovery-class orbiters without significant development cost increases. Benefits and drawbacks of Psyche’s approach are discussed, including comparison to other missions and tools where appropriate.

Ramanathan, Keshav↗

Factors influencing design and selection of GTAW robotic welding machines for the Space Shuttle main engine

Proposed hardware and software for microprocessor-controlled power supplies and welding machines are described. The application of the automatic seven-axis welding machine, which is to be preprogrammed to allow minimum intervention by the welding operator during the actual process, to the welding of the Space Shuttle main engine is discussed. The production requirements for the gas tungsten arc welds for the Space Shuttle main engine are examined. Consideration is given to positioner design, welding variables, inert shielding gas management, filler metal wire control, the up loading and down loading of data from off-line computers, process improvements, tooling, the welding variable library, and adaptive sensor control.

Flanigan, L.↗

Background issues for on-line aircraft documentation

Currently, almost all aircraft documentation in commercial aircraft cockpits is presented via hardcopy manuals. Several recent projects are aimed at eliminating all paper documentation in cockpits using electronic libraries. Electronic libraries encompass diverse information bases including aircraft system documentation, operations and procedures, checklists, maintenance logs, minimum equipment lists, maps and charts, and flight management information. These electronic libraries are envisioned to be embedded in the avionics so as to provide real time monitoring and display of information. Background issues are examined (motivation, information retrieval models, and preliminary designs) for the on-line presentation of aircraft systems documentation including operations, procedures, and checklists.

Russell, C. Ray↗

Engine structures modeling software system: Computer code. User's manual

ESMOSS is a specialized software system for the construction of geometric descriptive and discrete analytical models of engine parts, components and substructures which can be transferred to finite element analysis programs such as NASTRAN. The software architecture of ESMOSS is designed in modular form with a central executive module through which the user controls and directs the development of the analytical model. Modules consist of a geometric shape generator, a library of discretization procedures, interfacing modules to join both geometric and discrete models, a deck generator to produce input for NASTRAN and a 'recipe' processor which generates geometric models from parametric definitions. ESMOSS can be executed both in interactive and batch modes. Interactive mode is considered to be the default mode and that mode will be assumed in the discussion in this document unless stated otherwise.

Source record↗

NASA software documentation standard software engineering program

The NASA Software Documentation Standard (hereinafter referred to as Standard) can be applied to the documentation of all NASA software. This Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. This basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.

Source record↗

NASA Software Documentation Standard

The NASA Software Documentation Standard (hereinafter referred to as "Standard") is designed to support the documentation of all software developed for NASA; its goal is to provide a framework and model for recording the essential information needed throughout the development life cycle and maintenance of a software system. The NASA Software Documentation Standard can be applied to the documentation of all NASA software. The Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. The basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.

Source record↗

Generalized Support Software: Domain Analysis and Implementation

For the past five years, the Flight Dynamics Division (FDD) at NASA's Goddard Space Flight Center has been carrying out a detailed domain analysis effort and is now beginning to implement Generalized Support Software (GSS) based on this analysis. GSS is part of the larger Flight Dynamics Distributed System (FDDS), and is designed to run under the FDDS User Interface / Executive (UIX). The FDD is transitioning from a mainframe based environment to systems running on engineering workstations. The GSS will be a library of highly reusable components that may be configured within the standard FDDS architecture to quickly produce low-cost satellite ground support systems. The estimates for the first release is that this library will contain approximately 200,000 lines of code. The main driver for developing generalized software is development cost and schedule improvement. The goal is to ultimately have at least 80 percent of all software required for a spacecraft mission (within the domain supported by the GSS) to be configured from the generalized components.

Stark, Mike↗

Field Encapsulation Library The FEL 2.2 User Guide

This document describes version 2.2 of the Field Encapsulation Library (FEL), a library of mesh and field classes. FEL is a library for programmers - it is a "building block" enabling the rapid development of applications by a user. Since FEL is a library intended for code development, it is essential that enough technical detail be provided so that one can make full use of the code. Providing such detail requires some assumptions with respect to the reader's familiarity with the library implementation language, C++, particularly C++ with templates. We have done our best to make the explanations accessible to those who may not be completely C++ literate. Nevertheless, familiarity with the language will certainly help one's understanding of how and why things work the way they do. One consolation is that the level of understanding essential for using the library is significantly less than the level that one should have in order to modify or extend the library. One more remark on C++ templates: Templates have been a source of both joy and frustration for us. The frustration stems from the lack of mature or complete implementations that one has to work with. Template problems rear their ugly head particularly when porting. When porting C code, successfully compiling to a set of object files typically means that one is almost done. With templated C++ and the current state of the compilers and linkers, generating the object files is often only the beginning of the fun. On the other hand, templates are quite powerful. Used judiciously, templates enable more succinct designs and more efficient code. Templates also help with code maintenance. Designers can avoid creating objects that are the same in many respects, but not exactly the same. For example, FEL fields are templated by node type, thus the code for scalar fields and vector fields is shared. Furthermore, node type templating allows the library user to instantiate fields with data types not provided by the FEL authors. This type of flexibility would be difficult to offer without the support of the language. For users who may be having template-related problems, we offer the consolation that support for C++ templates is destined to improve with time. Efforts such as the Standard Template Library (STL) will inevitably drive vendors to provide more thorough, optimized tools for template code development. Furthermore, the benefits will become harder to resist for those who currently subscribe to the least-common-denominator "code it all in C" strategy. May FEL bring you both increased productivity and aesthetic satisfaction.

Moran, Patrick J.↗

A Distributed Simulation-to-Flight Framework to Support Investigating Trust/Trustworthiness in Multi-Agent Systems

As autonomous systems continue to grow both in use and complexity, the necessity for robust and extensible simulation-to-flight methods is paramount for establishing an effective architecture for autonomous systems. A fundamental objective of the ATTRACTOR (Autonomy Teaming and TRAjectories for Complex Trusted Operational Reliability) project was to design and develop a distributed mixed-reality simulation environment to begin establishing a basis for certification of autonomous systems via research into trust and trustworthiness. In this paper, we present an autonomous systems architecture and development framework paired with a persistent distributed modeling and simulation environment for test and evaluation of autonomous systems. The Autonomous Entity Operations Network (AEON) framework enables autonomous system development with an easily extensible collection of libraries and plug-n-play nodes facilitated by the Data Distribution Service (DDS) communication protocol standard. The Baseline Environment for Autonomous Modeling (BEAM) simulation environment is a distributed mixed-reality Unity™-based environment built around the same DDS communication paradigm allowing for easy integration with AEON-based autonomous applications. They were designed under ATTRACTOR in order to measure and establish trustworthiness and trust in single- and multi-agent human-machine systems whether these machines are fixed-wing general aviation, rotary-wing Unmanned Aerial Vehicles (UAVs), ground rovers, or even spacecraft. Together AEON and BEAM enable sim-to-flight with minimal configuration changes. By using AEON and BEAM, source code that runs in simulation ports directly to hardware and has successfully flown in the lab and in the National Airspace System (NAS) at NASA LaRC many times over the lifetime of ATTRACTOR.

Benjamin N Kelley↗

A Distributed Simulation-to-Flight Framework to Support Investigating Trust/Trustworthiness in Multi-Agent Systems

As autonomous systems continue to grow both in use and complexity, the necessity for robust and extensible simulation-to-flight methods is paramount for establishing an effective architecture for autonomous systems. A fundamental objective of the ATTRACTOR (Autonomy Teaming and TRAjectories for Complex Trusted Operational Reliability) project was to design and develop a distributed mixed-reality simulation environment to begin establishing a basis for certification of autonomous systems via research into trust and trustworthiness. In this paper, we present an autonomous systems architecture and development framework paired with a persistent distributed modeling and simulation environment for test and evaluation of autonomous systems. The Autonomous Entity Operations Network (AEON) framework enables autonomous system development with an easily extensible collection of libraries and plug-n-play nodes facilitated by the Data Distribution Service (DDS) communication protocol standard. The Baseline Environment for Autonomous Modeling (BEAM) simulation environment is a distributed mixed-reality Unity™-based environment built around the same DDS communication paradigm allowing for easy integration with AEON-based autonomous applications. They were designed under ATTRACTOR in order to measure and establish trustworthiness and trust in single- and multi-agent human-machine systems whether these machines are fixed-wing general aviation, rotary-wing Unmanned Aerial Vehicles (UAVs), ground rovers, or even spacecraft. Together AEON and BEAM enable sim-to-flight with minimal configuration changes. By using AEON and BEAM, source code that runs in simulation ports directly to hardware and has successfully flown in the lab and in the National Airspace System (NAS) at NASA LaRC many times over the lifetime of ATTRACTOR.

Benjamin N Kelley↗

Generic decommutation capabilities in the Space Flight Operations Center

A generic decommutation capability has been created as part of the Space Flight Operation Center's goal of developing a multimission telemetry system. Generic decommutation involves separating the algorithmic description for extracting data from the actual implementation of decommutation. This was done by creating a decommutation map language, which allows mission designers to describe decommutation algorithms without the restrictions imposed by a standard programming language. A decommutation map compiler converts this description into C code, which is then linked with a decommutation library to provide an executable decommutation program. So far, this approach has been used successfully to decommutate several different types of data.

O'Brien, Robin A.↗

Multi-media authoring - Instruction and training of air traffic controllers based on ASRS incident reports

This paper discusses the use of computer-assisted instructions and flight simulations to enhance procedural and perceptual motor task training. Attention is called to the fact that incorporating the accident and incident data contained in reports filed with the Aviation Safety Reporting System (ASRS) would be a valuable training tool which the learner could apply for other situations. The need to segment the events is emphasized; this would make it possible to modify events in order to suit the needs of the training environment. Methods were developed for designing meaningful scenario development on runway incursions on the basis of analysis of ASRS reports. It is noted that, while the development of interactive training tools using the ASRS and other data bases holds much promise, the design and production of interactive video programs and laser disks are very expensive. It is suggested that this problem may be overcome by sharing the costs of production to develop a library of materials available to a broad range of users.

Armstrong, Herbert B.↗

ASV3 dial-in interface recommendation for the Repository Based Software Engineering (RBSE) program

The purpose of this report is to provide insight into the approach and design of the Cooperative User Interface (CUI). The CUI is being developed based on Hypercard technology and will provide the same look and feel as is provided by the NASA Electronic Library System (NELS) X-Window interface. The interaction between the user and ASCII-LIB is presented as well as the set of Hypercard Cards with which the user will work.

Source record↗