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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 685 records · Page 38

All sources NASA NTRS DOE OSTI

NASA NTRS2008

Managing Complexity in Next Generation Robotic Spacecraft: From a Software Perspective

This presentation highlights the challenges in the design of software to support robotic spacecraft. Robotic spacecraft offer a higher degree of autonomy, however currently more capabilities are required, primarily in the software, while providing the same or higher degree of reliability. The complexity of designing such an autonomous system is great, particularly while attempting to address the needs for increased capabilities and high reliability without increased needs for time or money. The efforts to develop programming models for the new hardware and the integration of software architecture are highlighted.

Multi - threaded programming↗

NASA NTRS1987

Space station software reliability analysis based on failures observed during testing at the multisystem integration facility

Quality of software not only is vital to the successful operation of the space station, it is also an important factor in establishing testing requirements, time needed for software verification and integration as well as launching schedules for the space station. Defense of management decisions can be greatly strengthened by combining engineering judgments with statistical analysis. Unlike hardware, software has the characteristics of no wearout and costly redundancies, thus making traditional statistical analysis not suitable in evaluating reliability of software. A statistical model was developed to provide a representation of the number as well as types of failures occur during software testing and verification. From this model, quantitative measure of software reliability based on failure history during testing are derived. Criteria to terminate testing based on reliability objectives and methods to estimate the expected number of fixings required are also presented.

Tamayo, Tak Chai↗

NASA NTRS2003

XML: James Webb Space Telescope Database Issues, Lessons, and Status

This paper will present the current concept using extensible Markup Language (XML) as the underlying structure for the James Webb Space Telescope (JWST) database. The purpose of using XML is to provide a JWST database, independent of any portion of the ground system, yet still compatible with the various systems using a variety of different structures. The testing of the JWST Flight Software (FSW) started in 2002, yet the launch is scheduled for 2011 with a planned 5-year mission and a 5-year follow on option. The initial database and ground system elements, including the commands, telemetry, and ground system tools will be used for 19 years, plus post mission activities. During the Integration and Test (I&T) phases of the JWST development, 24 distinct laboratories, each geographically dispersed, will have local database tools with an XML database. Each of these laboratories database tools will be used for the exporting and importing of data both locally and to a central database system, inputting data to the database certification process, and providing various reports. A centralized certified database repository will be maintained by the Space Telescope Science Institute (STScI), in Baltimore, Maryland, USA. One of the challenges for the database is to be flexible enough to allow for the upgrade, addition or changing of individual items without effecting the entire ground system. Also, using XML should allow for the altering of the import and export formats needed by the various elements, tracking the verification/validation of each database item, allow many organizations to provide database inputs, and the merging of the many existing database processes into one central database structure throughout the JWST program. Many National Aeronautics and Space Administration (NASA) projects have attempted to take advantage of open source and commercial technology. Often this causes a greater reliance on the use of Commercial-Off-The-Shelf (COTS), which is often limiting. In our review of the database requirements and the COTS software available, only very expensive COTS software will meet 90% of requirements. Even with the high projected initial cost of COTS, the development and support for custom code over the 19-year mission period was forecasted to be higher than the total licensing costs. A group did look at reusing existing database tools and formats. If the JWST database was already in a mature state, the reuse made sense, but with the database still needing to handing the addition of different types of command and telemetry structures, defining new spacecraft systems, accept input and export to systems which has not been defined yet, XML provided the flexibility desired. It remains to be determined whether the XML database will reduce the over all cost for the JWST mission.

Detter, Ryan↗

NASA NTRS1974

Technical support for guidance, navigation and control space shuttle program

A review of the guidance, navigation and control projects in support of the space shuttle program was conducted. The subjects considered include the following: (1) functional and performance requirements, (2) mission requirements, (3) operating systems software definition, (4) orbit navigation using various sensors, (5) fault detection, isolation and recovery, and (6) passive rendezvous sensors requirements definition.

Source record↗

NASA NTRS2009

Data Analysis for the LISA Pathfinder Mission

The LTP (LISA Technology Package) is the core part of the Laser Interferometer Space Antenna (LISA) Pathfinder mission. The main goal of the mission is to study the sources of any disturbances that perturb the motion of the freely-falling test masses from their geodesic trajectories as well as 10 test various technologies needed for LISA. The LTP experiment is designed as a sequence of experimental runs in which the performance of the instrument is studied and characterized under different operating conditions. In order to best optimize subsequent experimental runs, each run must be promptly analysed to ensure that the following ones make best use of the available knowledge of the instrument ' In order to do this, all analyses must be designed and tested in advance of the mission and have sufficient built-in flexibility to account for unexpected results or behaviour. To support this activity, a robust and flexible data analysis software package is also required. This poster presents two of the main components that make up the data analysis effort: the data analysis software and the mock-data challenges used to validate analysis procedures and experiment designs.

Thorpe, James Ira↗

NASA NTRS2011

Gain Scheduling for the Orion Launch Abort Vehicle Controller

One of NASAs challenges for the Orion vehicle is the control system design for the Launch Abort Vehicle (LAV), which is required to abort safely at any time during the atmospheric ascent portion of ight. The focus of this paper is the gain design and scheduling process for a controller that covers the wide range of vehicle configurations and flight conditions experienced during the full envelope of potential abort trajectories from the pad to exo-atmospheric flight. Several factors are taken into account in the automation process for tuning the gains including the abort effectors, the environmental changes and the autopilot modes. Gain scheduling is accomplished using a linear quadratic regulator (LQR) approach for the decoupled, simplified linear model throughout the operational envelope in time, altitude and Mach number. The derived gains are then implemented into the full linear model for controller requirement validation. Finally, the gains are tested and evaluated in a non-linear simulation using the vehicles ight software to ensure performance requirements are met. An overview of the LAV controller design and a description of the linear plant models are presented. Examples of the most significant challenges with the automation of the gain tuning process are then discussed. In conclusion, the paper will consider the lessons learned through out the process, especially in regards to automation, and examine the usefulness of the gain scheduling tool and process developed as applicable to non-Orion vehicles.

McNamara, Sara J.↗

NASA NTRS1988

IDSE Version 1 User's Manual

The integrated development support environment (IDSE) is a suite of integrated software tools that provide intelligent support for information modelling. These tools assist in function, information, and process modeling. Additional tools exist to assist in gathering and analyzing information to be modeled. This is a user's guide to application of the IDSE. Sections covering the requirements and design of each of the tools are presented. There are currently three integrated computer aided manufacturing definition (IDEF) modeling methodologies: IDEF0, IDEF1, and IDEF2. Also, four appendices exist to describe hardware and software requirements, installation procedures, and basic hardware usage.

Mayer, Richard↗

NASA NTRS1984

A fault-tolerant software strategy for digital systems

Techniques developed for producing fault-tolerant software are described. Tolerance is required because of the impossibility of defining fault-free software. Faults are caused by humans and can appear anywhere in the software life cycle. Tolerance is effected through error detection, damage assessment, recovery, and fault treatment, followed by return of the system to service. Multiversion software comprises two or more versions of the software yielding solutions which are examined by a decision algorithm. Errors can also be detected by extrapolation from previous results or by the acceptability of results. Violations of timing specifications can reveal errors, or the system can roll back to an error-free state when a defect is detected. The software, when used in flight control systems, must not impinge on time-critical responses. Efforts are still needed to reduce the costs of developing the fault-tolerant systems.

Hitt, E. F.↗

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.↗