Search NASA⌕ Search

SEARCH · Search NASA

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

Strategic Center for Networking, Integration, and Communications Orbit Propagation Front-End Software Development

Orbit propagation is fundamental for space-based mission analysis, requiring software tools to predict the time-based positions and velocities of orbiting satellites. Many system analysts currently rely on commercial software, which is effective but expensive. NASA’s Space Communications and Navigation (SCaN) Strategic Center for Networking, Integration, and Communications (SCENIC) project intends to provide these analysis capabilities by using a combination of internal and open-source software, allowing for a greater flexibility while maintaining low costs. Several routines were created to take different forms of user input to translate input into the standard set of orbital elements to be utilized within the current SCENIC analysis capabilities. These inputs range from two-line elements (TLEs) and Cartesian vectors, to coordinate transformations and Walker Delta constellations. These routines will be integrated into the SCENIC user interface (UI) in order to provide greater customization and flexibility for orbit propagation and other dynamic-analysis capabilities.

Kuhl, Nick↗
NASA NTRS1987

A report on NASA software engineering and Ada training requirements

NASA's software engineering and Ada skill base are assessed and information that may result in new models for software engineering, Ada training plans, and curricula are provided. A quantitative assessment which reflects the requirements for software engineering and Ada training across NASA is provided. A recommended implementation plan including a suggested curriculum with associated duration per course and suggested means of delivery is also provided. The distinction between education and training is made. Although it was directed to focus on NASA's need for the latter, the key relationships to software engineering education are also identified. A rationale and strategy for implementing a life cycle education and training program are detailed in support of improved software engineering practices and the transition to Ada.

Legrand, Sue↗
NASA NTRS1976

Mission planning, mission analysis and software formulation. Level C requirements for the shuttle mission control center orbital guidance software

The formulation of Level C requirements for guidance software was reported. Requirements for a PEG supervisor which controls all input/output interfaces with other processors and determines which PEG mode is to be utilized were studied in detail. A description of the two guidance modes for which Level C requirements have been formulated was presented. Functions required for proper execution of the guidance software were defined. The requirements for a navigation function that is used in the prediction logic of PEG mode 4 were discussed. It is concluded that this function is extracted from the current navigation FSSR.

Langston, L. J.↗
NASA NTRS2006

Autonomy Software: V&V Challenges and Characteristics

The successful operation of unmanned air vehicles requires software with a high degree of autonomy. Only if high level functions can be carried out without human control and intervention, complex missions in a changing and potentially unknown environment can be carried out successfully. Autonomy software is highly mission and safety critical: failures, caused by flaws in the software cannot only jeopardize the mission, but could also endanger human life (e.g., a crash of an UAV in a densely populated area). Due to its large size, high complexity, and use of specialized algorithms (planner, constraint-solver, etc.), autonomy software poses specific challenges for its verification, validation, and certification. -- - we have carried out a survey among researchers aid scientists at NASA to study these issues. In this paper, we will present major results of this study, discussing the broad spectrum. of notions and characteristics of autonomy software and its challenges for design and development. A main focus of this survey was to evaluate verification and validation (V&V) issues and challenges, compared to the development of "traditional" safety-critical software. We will discuss important issues in V&V of autonomous software and advanced V&V tools which can help to mitigate software risks. Results of this survey will help to identify and understand safety concerns in autonomy software and will lead to improved strategies for mitigation of these risks.

Schumann, Johann↗
NASA NTRS1987

Flow visualization of CFD using graphics workstations

High performance graphics workstations are used to visualize the fluid flow dynamics obtained from supercomputer solutions of computational fluid dynamic programs. The visualizations can be done independently on the workstation or while the workstation is connected to the supercomputer in a distributed computing mode. In the distributed mode, the supercomputer interactively performs the computationally intensive graphics rendering tasks while the workstation performs the viewing tasks. A major advantage of the workstations is that the viewers can interactively change their viewing position while watching the dynamics of the flow fields. An overview of the computer hardware and software required to create these displays is presented. For complex scenes the workstation cannot create the displays fast enough for good motion analysis. For these cases, the animation sequences are recorded on video tape or 16 mm film a frame at a time and played back at the desired speed. The additional software and hardware required to create these video tapes or 16 mm movies are also described. Photographs illustrating current visualization techniques are discussed. Examples of the use of the workstations for flow visualization through animation are available on video tape.

Lasinski, Thomas↗
NASA NTRS1979

Spacelab interface development tests. Software description

The software requirements for the Spacelab Interface Development Tests are described. The software operates in two modes. The multiplexer-demultiplexer mode transmits operator-controlled information to the Spacelab. The pulse coded modulation (PCM) mode records and displays operator selected PCM data for visual analysis.

Akers, J. W.↗
NASA NTRS2000

Software Released by LEWICE 2.0 Ice Accretion Software Development Project

Computational icing simulation methods are making the transition from the realm of research to commonplace use in design and certification. As such, standards of software management, design, validation, and documentation must be adjusted to accommodate the increased expectations of the user community with respect to accuracy, reliability, capability, and usability. With this in mind, in collaboration with Glenn's Engineering Design and Analysis Division, the Icing Branch of the NASA Glenn Research Center at Lewis Field began a software improvement project focused on the two-dimensional ice accretion simulation tool LEWICE. This project is serving as an introduction to the concepts of software management and is intended to serve as a pilot project for future icing simulation code development. The LEWICE 2.0 Software Development Project consisted of two major elements: software management and software validation. The software management element consisted of identifying features of well-designed and well-managed software that are appropriate for an analytical prediction tool such as LEWICE and applying them to a revised version of the code. This element included tasks such as identification of software requirements, development and implementation of coding standards, and implementation of software revision control practices. With the application of these techniques, the LEWICE ice accretion code became a more stable and reliable software product. In addition, the lessons learned about software development and maintenance can be factored into future software projects at the outset. The software validation activity was an integral part of our effort to make LEWICE a more accurate and reliable analysis tool. Because of the efforts taken to extensively validate this software, LEWICE 2.0 is more robust than previous releases and can reproduce results accurately across several computing platforms. It also differs from previous versions in the extensive quantitative comparisons of its results with a data base of ice shapes that were generated in Glenn's Icing Research Tunnel. The results of the shape comparisons were analyzed to determine the range of meteorological conditions under which LEWICE 2.0 is within the repeatability found for ice shapes obtained from experiments. These comparisons show that the average variation of LEWICE 2.0 from experimental data is 7.2 percent, whereas the overall variability of the experimental data is 2.5 percent. The LEWICE 2.0 Software Development Project resulted in the release, at the recent Icing Branch LEWICE Workshop, of a more useful and robust analysis tool than was previously available to the icing community. The lessons learned from this project will be applied to the Icing Branch s future software development efforts.

Potapczuk, Mark G.↗
NASA NTRS1986

The testability of Ada programs

Software development for NASA's Space Station poses a significant problem; considered the most difficult by some. The difficulty is the magnitude and complexity of the required software. The concerns raised by consideration of the requirements for testing and checkout procedures for the Space Station software are addressed. In particular, it addresses the use of Ada in the development of widely distributed yet closely coordinated processing.

Auty, David↗
NASA NTRS1996

SEDSAT 1 Technologies

The original goals of this project were to support the development of SEDSAT 1 for a tethered launch in July of 1997. This specifically required: (1) Monitoring development progress against a comprehensive delivery plan; (2) Incremental development and release of CDS and SEASIS software; (3) Supporting the integration of version 1.0 SEASIS software that will allow minimal autonomous operation without a software reload. These algorithms would include image quality evaluation, attitude determination, and autonomous earth imaging; and (4) Developing software requirements and design for ground segment software, concentrating on command and data download capability; and interface to external development efforts for a more comprehensive software suite to be used after the initial mission. Because of an unfavorable space shuttle safety review of the SEDS-3 tether deployer, and cost and schedule problems in upgrading the deployer, the mission was changed to an independent launch of SEDSAT. The original plan was to do a tether-less deployment from the space shuttle. Since this would have resulted in an unacceptable orbital lifetime, the mission was changed again to a tethered launch from a Delta II in June 1998. As a result of Marshall Space Flight Center's redirection of the SEDS-3 mission away from a tether launch, the whole question of a tether endmass had to be reconsidered. The net result of these multiple changes was twofold. First, we completed work needed to define some aspects of ground software on SEDSAT 1 that would remain constant no matter the launch mode. Second, we developed a set of concepts for using SEDSAT 1 technology to support alternative endmass missions on SEDS-3. Both of these are included.

Maier, Mark W.↗
NASA NTRS2005

A Probabilistic Software System Attribute Acceptance Paradigm for COTS Software Evaluation

Standard software requirement formats are written from top-down perspectives only, that is, from an ideal notion of a client s needs. Despite the exactness of the standard format, software and system errors in designed systems have abounded. Bad and inadequate requirements have resulted in cost overruns, schedule slips and lost profitability. Commercial off-the-shelf (COTS) software components are even more troublesome than designed systems because they are often provided as is and subsequently delivered with unsubstantiated validation of described capabilities. For COTS software, there needs to be a way to express the client s software needs in a consistent and formal manner using software system attributes derived from software quality standards. Additionally, the format needs to be amenable to software evaluation processes that integrate observable evidence garnered from historical data. This paper presents a paradigm that effectively bridges the gap between what a client desires (top-down) and what has been demonstrated (bottom-up) for COTS software evaluation. The paradigm addresses the specification of needs before the software evaluation is performed and can be used to increase the shared understanding between clients and software evaluators about what is required and what is technically possible.

Morris, A. Terry↗
NASA NTRS1978

Description and performance of the Langley visual landing display system

A television/model board system is described which provides a means of generating a six-degree-of-freedom visual out-the-window scene for the pilot of a simulated aircraft. The hardware and its performance of capability for meeting the visual requirements for a wide range of simulation studies are detailed. Also included is a description of the computer software required for the system. An example of software implementation in a real-time computer program is provided.

Rollins, J. D.↗
NASA NTRS1996

An introduction to requirements capture using PVS: Specification of a simple autopilot

This paper presents an introduction to capturing software requirements in the PVS formal language. The object of study is a simplified digital autopilot that was motivated in part by the mode control panel of NASA Langley's Boeing 737 research aircraft. The paper first presents the requirements for this autopilot in English and then steps the reader through a translation of these requirements into formal mathematics. Along the way deficiencies in the English specification are noted and repaired. Once completed, the formal PVS requirement is analyzed using the PVS theorem prover and shown to maintain an invariant over its state space.

Butler, Ricky W.↗
NASA NTRS2017

OpenSatKit Enables Quick Startup for CubeSat Missions

The software required to develop, integrate, and operate a spacecraft is substantial regardless of whether its a large or small satellite. Even getting started can be a monumental task. To solve this problem, NASAs Core Flight System (cFS), NASA's 42 spacecraft dynamics simulator, and Ball Aerospaces COSMOS ground system have been integrated together into a kit called OpenSatKit that provides a complete and open source software solution for starting a new satellite mission. Users can have a working system with flight software, dynamics simulation, and a ground command and control system up and running within hours.Every satellite mission requires three primary categories of software to function. The first is Flight Software (FSW) which provides the onboard control of the satellites and its payload(s). NASA's cFS provides a great platform for developing this software. Second, while developing a satellite on earth, it is necessary to simulate the satellites orbit, attitude, and actuators, to ensure that the systems that control these aspects will work correctly in the real environment. NASAs 42 simulator provides these functionalities. Finally, the ground has to be able to communicate with the satellite, monitor its performance and health, and display its data. Additionally, test scripts have to be written to verify the system on the ground. Ball Aerospace's COSMOS command and control system provides this functionality. Once the OpenSatKit is up and running, the next step is to customize the platform and get it running on the end target. Starting from a fully working system makes porting the cFS from Linux to a users platform much easier. An example Raspberry Pi target is included in the kit so users can gain experience working with a low cost hardware target. All users can benefit from OpenSatKit but the greatest impact and benefits will be to SmallSat missions with constrained budgets and small software teams. This paper describes OpenSatKits system design, the steps necessary to run the system to target the Raspberry Pi, and future plans. OpenSatKit is a free fully functional spacecraft software system that we hope will greatly benefit the SmallSat community.

Software↗
NASA NTRS2013

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗
NASA NTRS1979

TMS communications software. Volume 1: Computer interfaces

A prototype bus communications system, which is being used to support the Trend Monitoring System (TMS) as well as for evaluation of the bus concept is considered. Hardware and software interfaces to the MODCOMP and NOVA minicomputers are included. The system software required to drive the interfaces in each TMS computer is described. Documentation of other software for bus statistics monitoring and for transferring files across the bus is also included.

Brown, J. S.↗
NASA NTRS1992

Functional requirements document for NASA/MSFC Earth Science and Applications Division: Data and information system (ESAD-DIS). Interoperability, 1992

These Earth Science and Applications Division-Data and Information System (ESAD-DIS) interoperability requirements are designed to quantify the Earth Science and Application Division's hardware and software requirements in terms of communications between personal and visualization workstation, and mainframe computers. The electronic mail requirements and local area network (LAN) requirements are addressed. These interoperability requirements are top-level requirements framed around defining the existing ESAD-DIS interoperability and projecting known near-term requirements for both operational support and for management planning. Detailed requirements will be submitted on a case-by-case basis. This document is also intended as an overview of ESAD-DIs interoperability for new-comers and management not familiar with these activities. It is intended as background documentation to support requests for resources and support requirements.

Stephens, J. Briscoe↗
NASA NTRS2000

Integrated tools and techniques applied to the TES ground data system

The author of this paper will dicuss the selection of CASE tools, a decision making process, requirements tracking and a review mechanism that leads to a highly integrated approach to software development that must deal with the constant pressure to change software requirements and design that is associated with research and development.

science data processing TES↗