Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Requirements”

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 847 records · Page 47
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

Software engineering environment tool set integration

Space Transportation System Division (STSD) Engineering has a program to promote excellence within the engineering function. This program resulted in a capital funded facility based on a VAX cluster called the Rockwell Operational Engineering System (ROSES). The second phase of a three phase plan to establish an integrated software engineering environment for ROSES is examined. It discusses briefly phase one which establishes the basic capability for a modern software development environment to include a tool set, training and standards. Phase two is a tool set integration. The tool set is primarily off-the-shelf tools acquired through vendors or government agencies (public domain). These tools were placed into categories of software development. These categories are: requirements, design, and construction support; verification and validation support; and software management support. The integration of the tool set is being performed through concept prototyping and development of tools specifically designed to support the life cycle and provide transition from one phase to the next.

Selfridge, William P.↗
NASA NTRS1989

A methodology for validating software reliability

A significant problem associated with fault tolerant computer system design is how to insure that there are no embedded software errors, so that an avionics computer system meets the required reliability level. To accomplish this, it is necessary to associate a 'probability of failure' with the operational flight program. It would be more correct to say that the probability of excitation of existing latent design errors within the program is required. In this sense, latent software errors are like latent hardware faults, and techniques that were previously used to measure the probability of failure of hardware due to fault latency can be used to measure the probability of failure of the software. A methodology was developed and applied to a flight control program that was known to operate in a well defined environment. The results indicated that the technique could be used to provide a final validation of the software to a specified reliability level and to evaluate the role of flight test in software validation.

Swern, Frederic L.↗
NASA NTRS2017

Space Science Investigation: NASA ISS Stowage Simulator

During this internship the opportunity was granted to work with the Integrated, Graphics, Operations and Analysis Laboratory (IGOAL) team. The main assignment was to create 12 achievement patches for the Space Station training simulator called the "NASA ISS Stowage Training Game." This project was built using previous IGOAL developed software. To accomplish this task, Adobe Photoshop and Adobe Illustrator were used to craft the badges and other elements required. Blender, a 3D modeling software, was used to make the required 3D elements. Blender was a useful tool to make things such as a CTB bag for the "No More Bob" patch which shows a gentleman kicking a CTB bag into the distance. It was also used to pose characters to the positions that was optimal for their patches as in the "Station Sanitation" patch which portrays and astronaut waving on a U.S module on a truck. Adobe Illustrator was the main piece of software for this task. It was used to craft the badges and upload them when they were completed. The style of the badges were flat, meaning that they shouldn't look three dimensional in any way, shape or form. Adobe Photoshop was used when any pictures need brightening and was where the texture for the CTB bag was made. In order for the patches to be ready for the game's next major release, they have to go under some critical reviewing, revising and re-editing to make sure the other artists and the rest of the staff are satisfied with the final products. Many patches were created and revamped to meet the flat setting and incorporate suggestions from the IGOAL team. After the three processes were completed, the badges were implemented into the game (reference fig1 for badges). After a month of designing badges, the finished products were placed into the final game build via the programmers. The art was the final piece in showcasing the latest build to the public for testing. Comments from the testers were often exceptional and the feedback on the badges were outstanding. The latest build will also be tested by astronauts to determine if the product could potentially be incorporated into the astronaut training program. This experience has provided the opportunity to experience the feeling of working with research and development organization. The art skills and programming skills received at the internship will provide and maintain and strong foundation for a career in computer programming and digital media.

Crawford, Gary↗
NASA NTRS1975

Tug fleet and ground operations schedules and controls. Volume 1: Executive summary

This study presents Tug Fleet and Ground Operations Schedules and Controls plan. This plan was developed and optimized out of a combination of individual Tug program phased subplans, special emphasis studies, contingency analyses and sensitivity analyses. The subplans cover the Tug program phases: (1) Tug operational, (2) Interim Upper Stage (IUS)/Tug fleet utilization, (3) and IUS/Tug payload integration, (4) Tug site activation, (5) IUS/Tug transition, (6) Tug acquisition. Resource requirements (facility, GSE, TSE, software, manpower, logistics) are provided in each subplan, as are appropriate Tug processing flows, active and total IUS and Tug fleet requirements, fleet management and Tug payload integration concepts, facility selection recommendations, site activation and IUS to Tug transition requirements. The impact of operational concepts on Tug acquisition is assessed and the impact of operating Tugs out of KSC and WTR is analyzed and presented showing WTR as a delta. Finally, cost estimates for fleet management and ground operations of the DDT&E and operational phases of the Tug program are given.

Source record↗
NASA NTRS1998

The Dependence of Signal-To-Noise Ratio (S/N) Between Star Brightness and Background on the Filter Used in Images Taken by the Vulcan Photometric Planet Search Camera

The Vulcan Photometric Planet Search is the ground-based counterpart of Kepler Mission Proposal. The Kepler Proposal calls for the launch of telescope to look intently at a small patch of sky for four year. The mission is designed to look for extra-solar planets that transit sun-like stars. The Kepler Mission should be able to detect Earth-size planets. This goal requires an instrument and software capable of detecting photometric changes of several parts per hundred thousand in the flux of a star. The goal also requires the continuous monitoring of about a hundred thousand stars. The Kepler Mission is a NASA Discovery Class proposal similar in cost to the Lunar Prospector. The Vulcan Search is also a NASA project but based at Lick Observatory. A small wide-field telescope monitors various star fields successively during the year. Dozens of images, each containing tens of thousands of stars, are taken any night that weather permits. The images are then monitored for photometric changes of the order of one part in a thousand. These changes would reveal the transit of an inner-orbit Jupiter-size planet similar to those discovered recently in spectroscopic searches. In order to achieve a one part in one thousand photometric precision even the choice of a filter used in taking an exposure can be critical. The ultimate purpose of an filter is to increase the signal-to-noise ratio (S/N) of one's observation. Ideally, filters reduce the sky glow cause by street lights and, thereby, make the star images more distinct. The higher the S/N, the higher is the chance to observe a transit signal that indicates the presence of a new planet. It is, therefore, important to select the filter that maximizes the S/N.

Mena-Werth, Jose↗
NASA NTRS2006

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and procedure for developing software. This paper will discuss the some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies.

Agile Development↗
NASA NTRS2006

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases, they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At the Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and processes for developing software. This paper will discuss some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies and processes.

software methodology↗
NASA NTRS1995

Electronic collection system for spacelab mission timeline requirements

This paper describes the Functional Objective Requirements Collection System (FORCS) software tool that has been developed for use by Principal Investigators (PI's) and Payload Element Developers (PED's) on their own personal computers to develop on-orbit timelining requirements for their payloads. The FORCS tool can be used either in a totally stand-alone mode, storing the information in a local file on the user's personal computer hard disk or in a remote mode where the user's computer is linked to a host computer containing the integrated database of the timeline requirements for all of the payloads on a mission. There are a number of features incorporated in the FORCS software to assist the user. The user may move freely back and forth between the various forms for inputting the data. Several methods are used to input the information, depending on the type of the information. These methods range from filling in text boxes, using check boxes and radio buttons, to inputting information into a spreadsheet format. There are automated features provided to assist in developing the proper format for the data, ranging from limit checking on some of the parameters to automatic conversion of different formats of time data inputs to the one standard format used for the timeline scheduling software.

Lindberg, James P.↗
NASA NTRS1992

LV software for supersonic flow analysis

The NASA Lewis Research Center (LeRC) maintains a leadership position in research into advanced aerospace propulsion systems. For the next generation of aircraft, engine designs continue to involve complex, high-speed flows. Performing the detailed flow diagnostics to properly evaluate these designs requires advanced instrumentation to probe these highly turbulent flows. The hostile flow environment often requires nonintrusive measurement techniques such as the laser velocimeter (LV). Since the LV is a proven instrument for nonintrusive flow measurement, it can provide quantitative velocity data with minimal interference to the flow. Based on anticipated flow conditions, laser velocimeter systems were procured from TSI, Inc. The initial system utilized counter processor technology, but later procurements this past year include a more advanced, correlator-based processor, which significantly improves the overall LV performance. To meet the needs of advanced research into propulsion, this instrument must be integrated into an existing VAX/VMS computer system for data acquisition, processing, and presentation. The work done under this grant before this period concentrated on developing the software required to setup and acquire data from the TSI MI-990 multichannel interface, and the RMR 1989 rotating machinery resolver. With the basis established for controlling the operation of the LV system, software development this past year shifted in emphasis from instrumentation control and data acquisition to data analysis and presentation. The progress of the program is reported.

Bell, William A.↗
NASA NTRS1998

Tropospheric- Stratospheric Measurement Studies Summary

The two high altitude aircraft, ER-2 NASA #706 and 709 and the DC-8 NASA #717 are in active use in several programs of upper atmospheric research to study polar ozone changes, stratospheric-tropospheric exchange processes and atmospheric effects of aviation aircraft. The ER-2 has participated in seven major missions which mainly concentrated on vortex dynamics and the large losses of Ozone in the Polar regions (Ozone hole) observed in the spring. One mission verified the complex dynamical chemical and physical processes that occur during sunrise and sunset. Stratospheric Tracers of Atmospheric Transport (STRAT) obtained background measurements using the full ER-2 suite of instruments. Photochemistry of Ozone Loss in the Arctic Region in Summer (POLARIS) in 1997 assisted in understanding the mid-latitude and Arctic Ozone losses during the Northern Summer. The DC-8 with the Meteorological Measurement System (MMS) has participated in the Subsonic Aircraft: Cloud and Contrail Effects Special Study (SUCCESS), in 1996 and the Subsonic assessment Ozone and Nitrogen oxide experiment (SONEX) in 1997 missions. The MMS with its sophisticated software accurately measures ground speed and attitude, in-situ static and dynamic pressure total temperature, which are used to calculate the three dimensional wind fields, static pressure, temperature and turbulence values to meteorological accuracy. The meteorological data is not only of interest for its own sake in atmospheric dynamical processes such as mountain waves and flux measurements; but is also required by other ER-2 experiments that simultaneously measure water vapor, O3, aerosols, NO, HCl, CH4, N2O, ClO, BrO, CO2, NOy, HOx and temperature gradients. MMS products are extensively used to assist in the interpretation of their results in understanding the importance of convective effects relative to in-situ chemical changes, as may be noted by examining the list of references attached. The MMS consists of three subsystems: (a) aircraft instrumentation, inertial navigation system (INS), static and dynamic pressure taps, (b) additional dedicated instrumentation measuring angle of attack, yaw, total temperature, and a GPS which on the DC-8 measures position, velocity and attitude (c) an on board data, storage and computing acquisition system. This instrumentation and the associated software requires both an on-going laboratory ground calibration procedure for the total air temperature, static and total pressure inputs, verification of the INS dynamic response and also extensive air measurements and intercomparisons which ultimately verify and calibrate the complete system and its software. More than the usual accuracy is required because of the near cancellation occurring in the difference between the ground speed and true airspeed vectors used to give the wind vector. In the past year we have redesigned, recalibrated and used the MMS system on the NASA DC-8 that was previously used in the SUCCESS mission for the SONEX mission. Two papers were co-authored based on SUCCESS flights. Several reports and handouts were written for SONEX. Calibrations of the DC-8 pressure transducer temperature measuring thermistors was completed and an extensive analysis spanning several years of data files of the DC-8 Rosemount pressure transducer calibrations was done.

Browen, Stuart W.↗
NASA NTRS2000

Software IV and V Research Priorities and Applied Program Accomplishments Within NASA

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

Blazy, Louis J.↗
NASA NTRS1991

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 NTRS1991

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↗
NASA NTRS1998

The Implementation of Satellite Control System Software Using Object Oriented Design

NASA established the Small Explorer (SMEX) program in 1988 to provide frequent opportunities for highly focused and relatively inexpensive space science missions that can be launched into low earth orbit by small expendable vehicles. The development schedule for each SMEX spacecraft was three years from start to launch. The SMEX program has produced five satellites; Solar Anomalous and Magnetospheric Particle Explorer (SAMPEX), Fast Auroral Snapshot Explorer (FAST), Submillimeter Wave Astronomy Satellite (SWAS), Transition Region and Coronal Explorer (TRACE) and Wide-Field Infrared Explorer (WIRE). SAMPEX and FAST are on-orbit, TRACE is scheduled to be launched in April of 1998, WIRE is scheduled to be launched in September of 1998, and SWAS is scheduled to be launched in January of 1999. In each of these missions, the Attitude Control System (ACS) software was written using a modular procedural design. Current program goals require complete spacecraft development within 18 months. This requirement has increased pressure to write reusable flight software. Object-Oriented Design (OOD) offers the constructs for developing an application that only needs modification for mission unique requirements. This paper describes the OOD that was used to develop the SMEX-Lite ACS software. The SMEX-Lite ACS is three-axis controlled, momentum stabilized, and is capable of performing sub-arc-minute pointing. The paper first describes the high level requirements which governed the architecture of the SMEX-Lite ACS software. Next, the context in which the software resides is explained. The paper describes the benefits of encapsulation, inheritance and polymorphism with respect to the implementation of an ACS software system. This paper will discuss the design of several software components that comprise the ACS software. Specifically, Object-Oriented designs are presented for sensor data processing, attitude control, attitude determination and failure detection. The paper addresses the benefits of the OOD versus a conventional procedural design. The final discussion in this paper will address the establishment of the ACS Foundation Class (AFC) Library. The AFC is a large software repository, requiring a minimal amount of code modifications to produce ACS software for future projects, saving production time and costs.

Anderson, Mark O.↗
NASA NTRS1976

Software handlers for process interfaces

The principles involved in the development of software handlers for custom interfacing problems are discussed. Handlers for the CAMAC standard are examined in detail. The types of transactions that must be supported have been established by standards groups, eliminating conflicting requirements arising out of different design philosophies and applications. Implementation of the standard handlers has been facilititated by standardization of hardware. The necessary local processors can be placed in the handler when it is written or at run time by means of input/output directives, or they can be built into a high-performance input/output processor. The full benefits of these process interfaces will only be realized when software requirements are incorporated uniformly into the hardware.

Bercaw, R. W.↗
NASA NTRS1973

Universal computer test stand (recommended computer test requirements)

Techniques are considered which would be used to characterize areospace computers with the space shuttle application as end usage. The system level digital problems which have been encountered and documented are surveyed. From the large cross section of tests, an optimum set is recommended that has a high probability of discovering documented system level digital problems within laboratory environments. Defined is a baseline hardware, software system which is required as a laboratory tool to test aerospace computers. Hardware and software baselines and additions necessary to interface the UTE to aerospace computers for test purposes are outlined.

Source record↗
NASA NTRS2015

Planning the Unplanned Experiment: Towards Assessing the Efficacy of Standards for Safety-Critical Software

Safe use of software in safety-critical applications requires well-founded means of determining whether software is fit for such use. While software in industries such as aviation has a good safety record, little is known about whether standards for software in safety-critical applications 'work' (or even what that means). It is often (implicitly) argued that software is fit for safety-critical use because it conforms to an appropriate standard. Without knowing whether a standard works, such reliance is an experiment; without carefully collecting assessment data, that experiment is unplanned. To help plan the experiment, we organized a workshop to develop practical ideas for assessing software safety standards. In this paper, we relate and elaborate on the workshop discussion, which revealed subtle but important study design considerations and practical barriers to collecting appropriate historical data and recruiting appropriate experimental subjects. We discuss assessing standards as written and as applied, several candidate definitions for what it means for a standard to 'work,' and key assessment strategies and study techniques and the pros and cons of each. Finally, we conclude with thoughts about the kinds of research that will be required and how academia, industry, and regulators might collaborate to overcome the noted barriers.

Graydon, Patrick J.↗
NASA NTRS1995

High Performance Parallel Computational Nanotechnology

At a recent press conference, NASA Administrator Dan Goldin encouraged NASA Ames Research Center to take a lead role in promoting research and development of advanced, high-performance computer technology, including nanotechnology. Manufacturers of leading-edge microprocessors currently perform large-scale simulations in the design and verification of semiconductor devices and microprocessors. Recently, the need for this intensive simulation and modeling analysis has greatly increased, due in part to the ever-increasing complexity of these devices, as well as the lessons of experiences such as the Pentium fiasco. Simulation, modeling, testing, and validation will be even more important for designing molecular computers because of the complex specification of millions of atoms, thousands of assembly steps, as well as the simulation and modeling needed to ensure reliable, robust and efficient fabrication of the molecular devices. The software for this capacity does not exist today, but it can be extrapolated from the software currently used in molecular modeling for other applications: semi-empirical methods, ab initio methods, self-consistent field methods, Hartree-Fock methods, molecular mechanics; and simulation methods for diamondoid structures. In as much as it seems clear that the application of such methods in nanotechnology will require powerful, highly powerful systems, this talk will discuss techniques and issues for performing these types of computations on parallel systems. We will describe system design issues (memory, I/O, mass storage, operating system requirements, special user interface issues, interconnects, bandwidths, and programming languages) involved in parallel methods for scalable classical, semiclassical, quantum, molecular mechanics, and continuum models; molecular nanotechnology computer-aided designs (NanoCAD) techniques; visualization using virtual reality techniques of structural models and assembly sequences; software required to control mini robotic manipulators for positional control; scalable numerical algorithms for reliability, verifications and testability. There appears no fundamental obstacle to simulating molecular compilers and molecular computers on high performance parallel computers, just as the Boeing 777 was simulated on a computer before manufacturing it.

Saini, Subhash↗