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.
Although not computer program, SMAP DIDS written to provide systematic, NASA-wide structure for documenting information system development projects. Each DID (data item description) outlines document required for top-quality software development. When combined with management, assurance, and life cycle standards, Standards protect all parties who participate in design and operation of new information system.
The MCNP-ORIGEN Activation Automation (MOAA) tool couples MCNP and ORIGEN-S, allowing to support ATR and TREAT experiments by predicting their composition and activity before their irradiation takes place. MOAA is developed and maintained by the Irradiation Experiment Neutronics Analysis group (C-150) at INL. This poster presents the motivation behind the development of MOAA, its main workflow, as well as the software quality assurance (SQA) efforts required by LWP-13620, "Managing Information Technology Assets."
Requirements have always been acknowledged as the backbone of any system. However, in many past development efforts, requirements were paid little heed. At NASA, in recent years, the hue and cry for project development has been "Faster, Better, Cheaper and Safer". This has impacted the way we develop software; it has increased the risks to quality, safety and reliability. At NASA, the Software Assurance Technology Center (SATC) is working with projects to emphasize the criticality of requirements throughout development, not just in the initial phases. This emphasis is on requirements relationship to all aspects of quality, including reliability and safety. In this presentation, we will look at some of these relationships through the eyes of quality.
The criticality of correct, complete, testable requirements is a fundamental tenet of software engineering. Also critical is complete requirements based testing of the final product. Modern tools for managing requirements allow new metrics to be used in support of both of these critical processes. Using these tools, potential problems with the quality of the requirements and the test plan can be identified early in the life cycle. Some of these quality factors include: ambiguous or incomplete requirements, poorly designed requirements databases, excessive or insufficient test cases, and incomplete linkage of tests to requirements. This paper discusses how metrics can be used to evaluate the quality of the requirements and test to avoid problems later. Requirements management and requirements based testing have always been critical in the implementation of high quality software systems. Recently, automated tools have become available to support requirements management. At NASA's Goddard Space Flight Center (GSFC), automated requirements management tools are being used on several large projects. The use of these tools opens the door to innovative uses of metrics in characterizing test plan quality and assessing overall testing risks. In support of these projects, the Software Assurance Technology Center (SATC) is working to develop and apply a metrics program that utilizes the information now available through the application of requirements management tools. Metrics based on this information provides real-time insight into the testing of requirements and these metrics assist the Project Quality Office in its testing oversight role. This paper discusses three facets of the SATC's efforts to evaluate the quality of the requirements and test plan early in the life cycle, thus preventing costly errors and time delays later.
It is common practice to write English-language "shall" statements to embody detailed software requirements in aerospace software applications. This paper explores the use of the UML language as a replacement for the English language for this purpose. Among the advantages offered by the Unified Modeling Language (UML) is a high degree of clarity and precision in the expression of domain concepts as well as architecture and design. Can this quality of UML be exploited for the definition of software requirements? While expressing logical behavior, interface characteristics, timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achieving the additional aspects of the expression and management of software requirements that stakeholders expect, especially traceability, is far less so. These other characteristics, concerned with auditing and quality control, include the ability to trace a requirement to a parent requirement (which may well be an English "shall" statement), to trace a requirement to verification activities or scenarios which verify that requirement, and to trace a requirement to elements of the software design which implement that requirement. UML Use Cases, designed for capturing requirements, have not always been satisfactory. Some applications of them simply use the Use Case model element as a repository for English requirement statements. Other applications of Use Cases, in which Use Cases are incorporated into behavioral diagrams that successfully communicate the behaviors and constraints required of the software, do indeed take advantage of UML's clarity, but not in ways that support the traceability features mentioned above. Our approach uses the Stereotype construct of UML to precisely identify elements of UML constructs, especially behaviors such as State Machines and Activities, as requirements, and also to achieve the necessary mapping capabilities. We describe this approach in the context of a space-based software application currently under development at the Jet Propulsion Laboratory.
Generating high quality, structured, continuous, body-fitted grid systems (multiblock grid systems) for complicated geometries has long been a most labor-intensive and frustrating part of simulating flows in complicated geometries. Recently, new methodologies and software have emerged that greatly reduce the human effort required to generate high quality multiblock grid systems for complicated geometries. These methods and software require minimal input form the user-typically, only information about the topology of the block structure and number of grid points. This paper demonstrates the use of the new breed of multiblock grid systems in simulations of internal flows in complicated geometries. The geometry used in this study is a duct with a sudden expansion, a partition, and an array of cylindrical pins. This geometry has many of the features typical of internal coolant passages in turbine blades. The grid system used in this study was generated using a commercially available grid generator. The simulations were done using a recently developed flow solver, TRAF3D.MB, that was specially designed to use multiblock grid systems.
This is a software-specific quality assurance plan (SQAP) for the X-Ray ToolKit (XTK) software that aligns with Sandia policy IT008, the SSQAP policy SS-R89727, and requirements related to DOE O 414.1D, Quality Assurance for software development.
This paper describes the use of Quality Function Deployment (QFD), adapted to requirements engineering for a software-intensive system development project, and sysnthesizes the lessons learned from the application of QFD to the Network Control System (NCS) pre-project of the Deep Space Network.
One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.
One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders
The mission of this research is to be world-class creators and facilitators of innovative, intelligent, high performance, reliable information technologies that enable NASA missions to (1) increase software safety and quality through error avoidance, early detection and resolution of errors, by utilizing and applying empirically based software engineering best practices; (2) ensure customer software risks are identified and/or that requirements are met and/or exceeded; (3) research, develop, apply, verify, and publish software technologies for competitive advantage and the advancement of science; and (4) facilitate the transfer of science and engineering data, methods, and practices to NASA, educational institutions, state agencies, and commercial organizations. The goals are to become a national Center Of Excellence (COE) in software and system independent verification and validation, and to become an international leading force in the field of software engineering for improving the safety, quality, reliability, and cost performance of software systems. This project addresses the following problems: Ensure safety of NASA missions, ensure requirements are met, minimize programmatic and technological risks of software development and operations, improve software quality, reduce costs and time to delivery, and improve the science of software engineering
The management of software engineering projects in the aerospace industry was investigated. The survey assessed such features as contract type, specification preparation techniques, software documentation required by customers, planning and cost-estimating, quality control, the use of advanced program practices, software tools and test procedures, the education levels of project managers, programmers and analysts, work assignment, automatic software monitoring capabilities, design and coding reviews, production times, success rates, and organizational structure of the projects.
Our purpose was to assess the use of machine learning methods and Mobius 3D (M3D) dose calculation software to reduce the number of physical ion chamber (IC) dose measurements required for patient-specific quality assurance during corona virus disease 2019.
Waiting until the integration and system test phase to discover errors leads to more costly rework than resolving those same errors earlier in the lifecycle. Costs increase even more significantly once a software system has become operational. WE can assess the quality of system requirements, but do little to correlate this information either to system assurance activities or long-term reliability projections - both of which remain unclear and anecdotal. Extending earlier work on requirements accomplished by the ARM tool, measuring requirements quality information against code complexity and test data for the same system may be used to predict specific software modules containing high impact or deeply embedded faults now escaping in operational systems. Such knowledge would lead to more effective and efficient test programs. It may enable insight into whether a program should be maintained or started over.
Several commercial applications of remote sensing data, such as water resources management, environmental monitoring, climate prediction, agriculture, forestry, preparation for and migration of extreme weather events, require access to vast amounts of archived high quality data, software tools and services for data manipulation and information extraction. These on the other hand require gaining detailed understanding of the data's internal structure and physical implementation of data reduction, combination and data product production. The time-consuming task must be undertaken before the core investigation can begin and is an especially difficult challenge when science objectives require users to deal with large multi-sensor data sets of different formats, structures, and resolutions.
Climate science and applications require access to vast amounts of archived high quality data, software tools and services for data manipulation and information extraction. These on the other hand require gaining detailed understanding of the data's internal structure and physical implementation to data reduction, combination and data product production. This time-consuming task must be undertaken before the core investigation can begin and is an especially difficult challenge when science objectives require users to deal with large multi-sensor data sets of different formats, structures, and resolutions. In order to address these issues the Goddard Space Flight Center (GSFC) Earth Sciences (GES), Data and Information Service Center (DISC) Distributed Active Archive Center (DAAC) has made great progress in facilitating science and applications research by developing innovative tools and data services applied to the Earth sciences atmospheric and climate data. The GES/DISC/DAAC has successfully implemented and maintained a long-term climate satellite data archive and developed tools and services to a variety of atmospheric science missions including AIRS, AVHRR, MODIS, SeaWiFS, SORCE, TOMS, TOVS, TRMM, and UARS and Aura instruments providing researchers with excellent opportunities to acquire accurate and continuous atmospheric measurements. Since the number of climate science products from these various missions is steadily increasing as a result of more sophisticated sensors and new science algorithms, the main challenge for data centers like the GES/DISC/DAAC is to guide users through the variety of data sets and products, provide tools to visualize and reduce the volume of the data and secure uninterrupted and reliable access to data and related products. This presentation will describe the effort at the GES/DISC/DAAC to build a bridge between multi-sensor data and the effective scientific use of the data, with an emphasis on the heritage satellite observations and science products for climate applications. The intent is to inform users of the existence of this large collection of data and products; suggest starting points for cross-platform science projects and data mining activities and provide data services and tools information. More information about the GES/DISC/DAAC satellite data and products, tools, and services can be found at http://daac.gsfc.nasa.gov.
In the international standards for architecture descriptions in systems and software engineering (ISO/IEC/IEEE 42010), "concern" is a primary concept that often manifests itself in relation to the quality attributes or "ilities" that a system is expected to exhibit - qualities such as reliability, security and modifiability. One of the main uses of an architecture description is to serve as a basis for analyzing how well the architecture achieves its quality attributes, and that requires architects to be as precise as possible about what they mean in claiming, for example, that an architecture supports "modifiability." This paper describes a table, generated by NASA's Software Architecture Review Board, which lists fourteen key quality attributes, identifies different important aspects of each quality attribute and considers each aspect in terms of requirements, rationale, evidence, and tactics to achieve the aspect. This quality attribute table is intended to serve as a guide to software architects, software developers, and software architecture reviewers in the domain of mission-critical real-time embedded systems, such as space mission flight software.
MOOSE-based physics codes require an input finite element mesh on which the physics solution is calculated, reported, and transferred to other physics codes. The use of difficult-touse, external licensed software is often required to generate high quality meshes for reactor geometries. High-fidelity geometry modeling also requires elaborate tracking of groups of elements for material property assignment and output reporting which can be considerably complex for the user to identify and maintain. Under the U.S. Department of Energy Office of Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, several meshingrelated enhancements have been developed for the MOOSE framework to address user challenges in creating finite element meshes for advanced reactor geometries. MOOSE mesh generators have been developed to mesh hexagonal geometries (pins, ducted assemblies, and cores) commonly found in liquid-metal cooled fast reactor concepts. The mesh generator used for hexagonal pin cells is generic for regular polygons and therefore may also be used for Cartesian pin cells. Hexagonal pin cells can be stitched into ducted assemblies, and assemblies can be stitched together into a core. The user may specify region ids, region names, and other preferences on the mesh. This control is useful for later material mapping in the MOOSE-based physics codes input. A capability was also developed for meshing rotating control drums including determination of material volume fractions in each mesh element as a function of time. Control drum meshes may be stitched to other hexagonal assemblies to create a core configuration. Additional mesh generators were developed that wrap around the hexagonal meshing capabilities and utilize “extra element integer” ID values on each element. In regular Cartesian or hexagonal assemblies or cores, the bookkeeping of element groups for both material assignment and output reporting can now be automated through assignment of pin, assembly, core, axial and depletion id values stored as extra element integers. The extra element tags on the mesh greatly speed the reactor analyst’s efforts to map materials to meshes, track depletion zones, and parse output such as axial pin power distributions. At the highest level, pin, assembly, and core mesh generators (with this reactor terminology) have also been developed to easily generate regular Cartesian and hexagonal cores, including axial extrusion. These reactor geometry builders call upon the previously mentioned capabilities to produce analysis-ready 3D meshes including material assignments. Open source mesh triangulation capabilities were also investigated for integration into the MOOSE framework to address the need for meshing the core periphery region which extends from the irregular outer assembly border to a cylindrical boundary. Options are limited due to licensing constraints, and the recommendation is pursue building a native MOOSE Delaunay triangulator routine with full functionality. Finally, a series of verification problems were performed with NEAMS physics tools. All developed capabilities will be available in the new open-source “Reactor” module of the MOOSE framework, which is accessible to any MOOSE-based NEAMS physics tool.