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 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
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.↗
DOE OSTI2022

Qualification of SAS4A/SASSYS-1 for Sodium-Cooled Fast Reactor Authorization and Licensing (Final CRADA Report)

This project focuses on assessment and qualification of the SAS4A/SASSYS-1 advanced reactor safety analysis code and its capacity to fulfill requirements associated with license/authorization of a sodium-cooled fast reactor (SFR). Specific objectives of this proposal include: development of a formal documentation requirements matrix that complies with a vendor’s NQA-1 program to identify needs for qualification documentation; completion of software methods qualification gap analysis to identify and close gaps in the verification and validation basis of the software; generation of an Acceptance Test Report to confirm compliance with the software requirements specification; and closure of gaps in Software Design Description (SDD) to assist with the eventual generation of a Modeling Licensing Topic Report (LTR).

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
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.↗
DOE OSTI2024

FARM User Guidance and Instructions

The FARM (Feasible Actuator Range Modifier) module is a component of the RAVEN-based FORCE framework for the analysis of Integrated Energy Systems (IES). FARM aids HERON in the solution of the power dispatch problem by evaluating feasible set-point signals to be issued to the control systems of the different IES unit components. Set-points need to satisfy limits on both production variables (i.e., the variables to be optimized such as the electrical power, etc.) and process variables tied to the service life of equipment (e.g., steam flowrate, vessel pressure, turbine firing temperature, etc.). To enforce all these limits, a two-stage approach is adopted. First, the power dispatcher algorithm in HERON module estimates set-points that meet the constraints on the production variables, e.g., power levels and power ramp rate limits. These constraints are called explicit constraints. Then, if necessary, FARM adjusts these set-points to ensure the respect of the limits on the process variables of interest, given the knowledge of the system dynamics acquired through machine learning algorithms. These constraints are called implicit constraints. From this standpoint, FARM constitutes a bridge between the HERON power dispatcher that adopts a simplified description of the IES unit (low-resolution physics) and the HYBRID high-fidelity models (high-resolution physics). In this report, the general workflow and the software requirements of FARM module are summarized, and the detailed instructions for installing FARM software, running built-in example cases, deriving Linear Parameter-Varying (LPV) state-space models, and using FARM for user-defined power dispatch problems are provided.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
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↗
NASA NTRS1976

Payload specialist station study. Volume 3: Program study cost estimates. Part 1: Work breakdown structure

The work breakdown structure (WBS) for the Payload Specialist Station (PSS) is presented. The WBS is divided into two elements--PSS contractor and mission unique requirements. In accordance with the study ground rules, it is assumed that a single contractor, hereafter referred to as PSS Contractor will perform the following: (1) provide C and D hardware (MFDS and elements of MMSE), except for GFE; (2) identify software requirements; (3) provide GSE and ground test software; and (4) perform systems engineering and integration in support of the Aft Flight Deck (AFD) C and D concept. The PSS Contractor WBS element encompasses a core or standardized PSS concept. Payload peculiar C and D requirements identified by users will originate as a part of the WBS element mission unique requirements; these requirements will be provided to the PSS Contractor for implementation.

Source record↗
NASA NTRS1989

Spacelab system analysis: The modified free access protocol: An access protocol for communication systems with periodic and Poisson traffic

The protocol definition and terminal hardware for the modified free access protocol, a communications protocol similar to Ethernet, are developed. A MFA protocol simulator and a CSMA/CD math model are also developed. The protocol is tailored to communication systems where the total traffic may be divided into scheduled traffic and Poisson traffic. The scheduled traffic should occur on a periodic basis but may occur after a given event such as a request for data from a large number of stations. The Poisson traffic will include alarms and other random traffic. The purpose of the protocol is to guarantee that scheduled packets will be delivered without collision. This is required in many control and data collection systems. The protocol uses standard Ethernet hardware and software requiring minimum modifications to an existing system. The modification to the protocol only affects the Ethernet transmission privileges and does not effect the Ethernet receiver.

Ingels, Frank↗
NASA NTRS1992

Software design for automated assembly of truss structures

Concern over the limited intravehicular activity time has increased the interest in performing in-space assembly and construction operations with automated robotic systems. A technique being considered at LaRC is a supervised-autonomy approach, which can be monitored by an Earth-based supervisor that intervenes only when the automated system encounters a problem. A test-bed to support evaluation of the hardware and software requirements for supervised-autonomy assembly methods was developed. This report describes the design of the software system necessary to support the assembly process. The software is hierarchical and supports both automated assembly operations and supervisor error-recovery procedures, including the capability to pause and reverse any operation. The software design serves as a model for the development of software for more sophisticated automated systems and as a test-bed for evaluation of new concepts and hardware components.

Herstrom, Catherine L.↗
NASA NTRS1992

An experimental methodology for a fuzzy set preference model

A flexible fuzzy set preference model first requires approximate methodologies for implementation. Fuzzy sets must be defined for each individual consumer using computer software, requiring a minimum of time and expertise on the part of the consumer. The amount of information needed in defining sets must also be established. The model itself must adapt fully to the subject's choice of attributes (vague or precise), attribute levels, and importance weights. The resulting individual-level model should be fully adapted to each consumer. The methodologies needed to develop this model will be equally useful in a new generation of intelligent systems which interact with ordinary consumers, controlling electronic devices through fuzzy expert systems or making recommendations based on a variety of inputs. The power of personal computers and their acceptance by consumers has yet to be fully utilized to create interactive knowledge systems that fully adapt their function to the user. Understanding individual consumer preferences is critical to the design of new products and the estimation of demand (market share) for existing products, which in turn is an input to management systems concerned with production and distribution. The question of what to make, for whom to make it and how much to make requires an understanding of the customer's preferences and the trade-offs that exist between alternatives. Conjoint analysis is a widely used methodology which de-composes an overall preference for an object into a combination of preferences for its constituent parts (attributes such as taste and price), which are combined using an appropriate combination function. Preferences are often expressed using linguistic terms which cannot be represented in conjoint models. Current models are also not implemented an individual level, making it difficult to reach meaningful conclusions about the cause of an individual's behavior from an aggregate model. The combination of complex aggregate models and vague linguistic preferences has greatly limited the usefulness and predictive validity of existing preference models. A fuzzy set preference model that uses linguistic variables and a fully interactive implementation should be able to simultaneously address these issues and substantially improve the accuracy of demand estimates. The parallel implementation of crisp and fuzzy conjoint models using identical data not only validates the fuzzy set model but also provides an opportunity to assess the impact of fuzzy set definitions and individual attribute choices implemented in the interactive methodology developed in this research. The generalized experimental tools needed for conjoint models can also be applied to many other types of intelligent systems.

Turksen, I. B.↗
NASA NTRS2001

Architectures and Evaluation for Adjustable Control Autonomy for Space-Based Life Support Systems

In the past five years, a number of automation applications for control of crew life support systems have been developed and evaluated in the Adjustable Autonomy Testbed at NASA's Johnson Space Center. This paper surveys progress on an adjustable autonomous control architecture for situations where software and human operators work together to manage anomalies and other system problems. When problems occur, the level of control autonomy can be adjusted, so that operators and software agents can work together on diagnosis and recovery. In 1997 adjustable autonomy software was developed to manage gas transfer and storage in a closed life support test. Four crewmembers lived and worked in a chamber for 91 days, with both air and water recycling. CO2 was converted to O2 by gas processing systems and wheat crops. With the automation software, significantly fewer hours were spent monitoring operations. System-level validation testing of the software by interactive hybrid simulation revealed problems both in software requirements and implementation. Since that time, we have been developing multi-agent approaches for automation software and human operators, to cooperatively control systems and manage problems. Each new capability has been tested and demonstrated in realistic dynamic anomaly scenarios, using the hybrid simulation tool.

Malin, Jane T.↗
NASA NTRS1975

Evaluation of several navigation algorithms for application to general aviation

Using data obtained in flight, three position determining algorithms for use by general aviation aircraft were evaluated representing increasing software requirements. These were a DME only, DME/air data and blended DME/air data. Although each step represented additional software with resultant increase in position accuracy, all could be performed on a programmable electronic desk calculator. Results from the computation of aircraft position using the three algorithms are presented. The algorithms employed can be extended to accept VOR, TACAN bearing, ADF, or other NAVAID Data. To obtain the flight data an experimental system was configured and flown on a general aviation aircraft. Principal hardware elements (all with low-cost potential) were a programmable calculator, a single DME receiver (multiplexed for multiple DME use) and a low-cost air speed sensor (shed-vortex principle). The flight test demonstrated satisfactory performance of these principal elements.

Conrad, B.↗
NASA NTRS1977

NASA software specification and evaluation system: Software verification/validation techniques

NASA software requirement specifications were used in the development of a system for validating and verifying computer programs. The software specification and evaluation system (SSES) provides for the effective and efficient specification, implementation, and testing of computer software programs. The system as implemented will produce structured FORTRAN or ANSI FORTRAN programs, but the principles upon which SSES is designed allow it to be easily adapted to other high order languages.

Source record↗