SEARCH · Engineering Papers
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.
The road blocks and mental blocks in areas where automation is not taking care of basic documentation problems are discussed. Original project documentation, documentation for project maintenance, and comparison of preliminary and final documentation are described. The use of flow charts is also mentioned.
There are no author-identified significant results in this report.
The objective of the Project Analysis and Integration Area (PA&I) is to support the planning, analysis, integration, and decision making activities of the Flat-plate Solar Array FSA) Project. Accordingly, PA&I supports the Project by developing and documenting Project plans based, in part, on the technical and economic assessments performed by PA&I of the various technical options. Goals for module technical performance and costs, derived from National Photovoltaics Program goals, are established by PA&I for each of the major technical activities in the Project. Assessments of progress toward achievement of goals are made to guide decision making within the Project.
An ongoing technical assessment and requirements definition project is examining the potential role of digital imaging technology at NASA's STI facility. The focus is on the basic components of imaging technology in today's marketplace as well as the components anticipated in the near future. Presented is a requirement specification for a prototype project, an initial examination of current image processing at the STI facility, and an initial summary of image processing projects at other sites. Operational imaging systems incorporate scanners, optical storage, high resolution monitors, processing nodes, magnetic storage, jukeboxes, specialized boards, optical character recognition gear, pixel addressable printers, communications, and complex software processes.
All software systems of significant size and longevity eventually undergo changes to their basic architectural structure. Such changes may be prompted by evolving requirements, changing technology, or other reasons. Whatever the cause, software architecture evolution is commonplace in real world software projects. Recently, software architecture researchers have begun to study this phenomenon in depth. However, this work has suffered from problems of validation; research in this area has tended to make heavy use of toy examples and hypothetical scenarios and has not been well supported by real world examples. To help address this problem, I describe an ongoing effort at the Jet Propulsion Laboratory to re-architect the Advanced Multimission Operations System (AMMOS), which is used to operate NASA's deep-space and astrophysics missions. Based on examination of project documents and interviews with project personnel, I describe the goals and approach of this evolution effort and then present models that capture some of the key architectural changes. Finally, I demonstrate how approaches and formal methods from my previous research in architecture evolution may be applied to this evolution, while using languages and tools already in place at the Jet Propulsion Laboratory.
This slide presentation reviews the study to understand the changes in cost and schedule growth for NASA projects. A second goal was to determine the percentage of growth that was outside the control of the project. The study examined project documentation, conducted interviews with key project personnel, and allocated growth events to an Explanation of Change (EoC) tree to quantify the reasons for growth in the scheduled time. This briefing reviews the results of the study of the first 20 missions.
The Offshore Code Comparison Collaboration 7 (OC7) project is organized under the International Energy Agency Wind Technology Collaboration Programme Task 56 with an objective to evaluate and enhance the predictive accuracy of engineering-level modeling tools used in the design of offshore wind energy systems. Phase I of OC7 is focused on improving the models and modeling practices of hydrodynamic viscous loads on floating offshore wind turbine platforms. In alignment with this goal, Work Package 1.1 of OC7 Phase I is formulated to investigate the modeling of hydrodynamic viscous loads on several different geometric components commonly encountered with floating offshore wind platform designs, including cylindrical columns, heave plates, and rectangular pontoons. Work Package 1.1 also explores the dependence of hydrodynamic coefficients on the sea state to drive toward practical guidance on how these coefficients can be selected or adjusted for different conditions. This report outlines the motivation and objectives behind each subphase of OC7 Phase I, along with the necessary technical specifications and load case definitions to guide the project participants. It also serves as an important part of the project documentation for future modelers who would like to reproduce this work or make use of the data and information generated from the OC7 project.
The ALICE-USA Barrel Tracking Upgrade (BTU) project began in 2015 to participate in a major upgrade of the Time Projection Chamber (TPC) and the Inner Tracking System (ITS) of the ALICE Experiment at CERN in Geneva, Switzerland. This upgrade increased the maximum readout rate of the ALICE detector to accommodate the increased heavy ion interaction rates following Long Shutdown 2 of the Large Hadron Collider, and greatly improved the vertexing performance of the detector. The original scope was completed and reviewed in November 2019. The BTU project document BTU.19.v1 "ALICE Barrel Tracking Upgrade Project Closeout / Transition to Operations (2019)" from November 2019 describes the status in detail and is attached as Appendix 1 below. At that point, all delivery milestones had been met on time, all Key Performance Parameters (KPPs) of the project had been satisfied, and the project was under budget. Several subsequent No Cost Extensions (NCEs) supported integration and pre-commissioning of the BTU project deliverables at CERN, as well as study and assessment of performance with Pb-Pb collisions at 50 kHz. The BTU project was successfully completed on 30 September 2024.
An orbiting coherent Doppler lidar for measuring winds is required to provide two basic pieces of data to the user community. The first is the line of sight wind velocity and the second is knowledge of the position at which the measurement was made. In order to obtain this data for targets of interest to the atmospheric community the instrument must also have a level of backscatter sensitivity sufficient to achieve the goal. Sensitivity analyses for the line of sight velocity and position requirements for two lidar instruments, one with a nadir angle of 30 deg. in a 300 km altitude, 58 deg. inclination orbit and the second for a 45 deg. nadir angle instrument in a 833 km altitude , 89 deg. inclination orbit are performed. The issues relating to the backscatter sensitivity of a coherent lidar have been well documented previously and are not discussed here other than to identify a space-specific issue that does not typically need to be considered for ground and aircraft based coherent lidars. Section 2 and appendices A1 and A2 document these sensitivity analyses. This contract was intended to develop requirements for a space shuttle (STS) based coherent lidar however, shortly after the award of this contract NASA MSFC won the SPARCLE program to put a coherent Doppler lidar on STS. Consequently much of the work conducted under this contract has been documented within the development of the SPARCLE project documentation. The relevant portions of the SPARCLE documentation are identified in section 3.0 and included in appendices A3 and A4. Section 4.0 briefly outlines miscellaneous other activities that occurred under this contract.
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.
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.
This report is a document tree of the safety and integration documents required to develop a space experiment. Pertinent document information for each of the top level (tier one) safety and integration documents, and their applicable and reference (tier two) documents has been identified. This information includes: document title, revision level, configuration management, electronic availability, listed applicable and reference documents, source for obtaining the document, and document owner. One of the main conclusions of this report is that no single document tree exists for all safety and integration documents, regardless of the Shuttle carrier. This document also identifies the need for a single point of contact for customers wishing to access documents. The data in this report serves as a valuable information source for the NASA Lewis Research Center Project Documentation Center, as well as for all developers of space experiments.
This follow-on to NASA Contractor Report 195447, Microgravity Experiments Safety and Integration Requirements Document Tree, provides the details for accessing the systems that contain the official, electronic versions of the documents initially researched in NASA Contractor Report 195447. The data in this report serves as a valuable information source for the NASA Lewis Research Center Project Documentation Center (PDC), as well as for all developers of space experiments. The PDC has acquired the hardware, software, ID's, and passwords necessary to access most of these systems and is now able to provide customers with current document information as well as immediate delivery of available documents in either electronic or hard copy format.
We briefly describe a system for forms-based, work-flow management that helps members of a software development team overcome geographical barriers to collaboration. Our system, called the Web Integrated Software Environment (WISE), is implemented as a World-Wide-Web service that allows for management and measurement of software development projects based on dynamic analysis of change activity in the workflow. WISE tracks issues in a software development process, provides informal communication between the users with different roles, supports to-do lists, and helps in software process improvement. WISE minimizes the time devoted to metrics collection and analysis by providing implicit delivery of messages between users based on the content of project documents. The use of a database in WISE is hidden from the users who view WISE as maintaining a personal 'to-do list' of tasks related to the many projects on which they may play different roles.
Starting in 2017, NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) element began a systems engineering transition from traditional, document-centric development to model-centric development when defining its foundation medical systems. These foundation medical systems define a Concept of Operations (ConOps) and identify the generic requirements for a medical system based on assumptions about a generic crew and mission environments and guidance from NASA standards (e.g., Medical “Levels of Care”). By making the transition, ExMC intends to improve communication among stakeholders about foundation medical system requirements and content. In addition, this transition will enable ExMC to lower both development and crew treatment risks for future, mission-specific medical systems. ExMC followed a Model Based Systems Engineering (MBSE) paradigm when developing the foundation medical systems. A model-based approach provides several advantages over a traditional, document-centric approach. First, when Systems Engineers (SE) develop diagrams in a model using a standard modeling language, they produce information dense pictures that facilitate understanding much more efficiently with less room for misinterpretation than text. Second, due to the evolving nature of projects, documentation becomes out of date the minute it is published. This can result in people making decisions based on information that is no longer current, especially if they are referencing a locally-stored copy of a document. A model, on the other hand, is always up to date with the latest approved changes and information. It serves as a single point of truth. Third, a model-centric approach centralizes all important information in one place. Rather than having to flip through separate ConOps documents, design specifications, requirements specifications, and the like to coordinate information, a model captures the content in one, integrated spot. This integration makes tracing information from end-to-end easier with greater reliability. The ExMC Systems Engineering Lifecycle follows a well-defined process. ExMC Systems Engineers perform all major steps of the process, regardless of the development methodology. One of the first steps in the process is developing the ConOps that describes the operation of the system from the point of view of the users. It includes a list of the users and their needs, the goals of the medical system, key assumptions about the system, and definitions of the medical system’s operational environments. For this development effort, ExMC chose to replace the traditional text-based ConOps document with a model. While the decision to change the development workflow was not difficult, implementing the structural and organizational workflows were. It required showing ExMC’s users, most of whom are not Systems Engineers, how the information they require would be presented in the model and to gain their acceptance of this approach. This paper documents key lessons learned during the ConOps transformation by focusing on how the model represents information, the agile workflow used by SEs when developing the model and how it integrates into a project plan, how leadership influenced key users to accept the transformation, and how the users interact with the model information.
The challenge of a global operations capability led to the Telescience Resource Kit (TReK) project, an in-house software development project of the Mission Operations Laboratory (MOL) at NASA's Marshall Space Flight Center (MSFC). The TReK system is being developed as an inexpensive comprehensive personal computer- (PC-) based ground support system that can be used by payload users from their home sites to interact with their payloads on board the International Space Station (ISS). The TReK project is currently using a combination of the spiral lifecycle model and the incremental lifecycle model. As with any software development project, there are four activities that can be very time consuming: Software design and development, project documentation, testing, and umbrella activities, such as quality assurance and configuration management. In order to produce a quality product, it is critical that each of these activities receive the appropriate amount of attention. For TReK, the challenge was to lay out a lifecycle and project plan that provides full support for these activities, is flexible, provides a way to deal with changing risks, can accommodate unknowns, and can respond to changes in the environment quickly. This paper will provide an overview of the TReK lifecycle, a description of the project's environment, and a general overview of project activities.
With the advancement and adoption of Additive Manufacturing (AM) for spaceflight systems, numerous lessons have been learned during the qualification and certification of AM components. The lessons learned covered in this presentation will provide an overview of the challenges faced by NASA centers and commercial partners working to design AM hardware that complies with NASA-STD-6030 Additive Manufacturing Requirements (AMR). Topics of interest include tailoring of requirements for specific projects, documentation requirements, and addressing conservative approaches towards mechanical property development and analysis. In addition to that, this presentation aims to impress that these lessons learned will influence the future revisions of the NASA technical standard to facilitate and advance AM technology adoption on NASA projects.
A document-retrieval assistant (DRA) in a microcomputer format is described which incorporates hypertext and natural language capabilities. Hypertext is used to introduce an intelligent search capability, and the natural-language interface permits access to specific data without the use of keywords. The DRA can be used to access and 'browse' the large multimedia database that is composed of project documentation from the HST.