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 1,639 records · Page 91
All sourcesNASA NTRSDOE OSTI
NASA NTRS2009

A Reference Model for Software and System Inspections. White Paper

Software Quality Assurance (SQA) is an important component of the software development process. SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. Typical techniques include: (1) Testing (2) Simulation (3) Model checking (4) Symbolic execution (5) Management reviews (6) Technical reviews (7) Inspections (8) Walk-throughs (9) Audits (10) Analysis (complexity analysis, control flow analysis, algorithmic analysis) (11) Formal method Our work over the last few years has resulted in substantial knowledge about SQA techniques, especially the areas of technical reviews and inspections. But can we apply the same QA techniques to the system development process? If yes, what kind of tailoring do we need before applying them in the system engineering context? If not, what types of QA techniques are actually used at system level? And, is there any room for improvement.) After a brief examination of the system engineering literature (especially focused on NASA and DoD guidance) we found that: (1) System and software development process interact with each other at different phases through development life cycle (2) Reviews are emphasized in both system and software development. (Figl.3). For some reviews (e.g. SRR, PDR, CDR), there are both system versions and software versions. (3) Analysis techniques are emphasized (e.g. Fault Tree Analysis, Preliminary Hazard Analysis) and some details are given about how to apply them. (4) Reviews are expected to use the outputs of the analysis techniques. In other words, these particular analyses are usually conducted in preparation for (before) reviews. The goal of our work is to explore the interaction between the Quality Assurance (QA) techniques at the system level and the software level.

He, Lulu↗
NASA NTRS1989

Computer-aided software development process design

The authors describe an intelligent tool designed to aid managers of software development projects in planning, managing, and controlling the development process of medium- to large-scale software projects. Its purpose is to reduce uncertainties in the budget, personnel, and schedule planning of software development projects. It is based on dynamic model for the software development and maintenance life-cycle process. This dynamic process is composed of a number of time-varying, interacting developmental phases, each characterized by its intended functions and requirements. System dynamics is used as a modeling methodology. The resulting Software LIfe-Cycle Simulator (SLICS) and the hybrid expert simulation system of which it is a subsystem are described.

Lin, Chi Y.↗
NASA NTRS1993

Analysis of a hardware and software fault tolerant processor for critical applications

Computer systems for critical applications must be designed to tolerate software faults as well as hardware faults. A unified approach to tolerating hardware and software faults is characterized by classifying faults in terms of duration (transient or permanent) rather than source (hardware or software). Errors arising from transient faults can be handled through masking or voting, but errors arising from permanent faults require system reconfiguration to bypass the failed component. Most errors which are caused by software faults can be considered transient, in that they are input-dependent. Software faults are triggered by a particular set of inputs. Quantitative dependability analysis of systems which exhibit a unified approach to fault tolerance can be performed by a hierarchical combination of fault tree and Markov models. A methodology for analyzing hardware and software fault tolerant systems is applied to the analysis of a hypothetical system, loosely based on the Fault Tolerant Parallel Processor. The models consider both transient and permanent faults, hardware and software faults, independent and related software faults, automatic recovery, and reconfiguration.

Dugan, Joanne B.↗
NASA NTRS1995

Lightning forecasting studies using LDAR, LLP, field mill, surface mesonet, and Doppler radar data

The ultimate goal of this research is to develop rules, algorithms, display software, and training materials that can be used by the operational forecasters who issue weather advisories for daily ground operations and launches by NASA and the United States Air Force to improve real-time forecasts of lightning. Doppler radar, Lightning Detection and Ranging (LDAR), Lightning Location and Protection (LLP), field mill (Launch Pad Lightning Warning System -- LPLWS), wind tower (surface mesonet) and additional data sets have been utilized in 10 case studies of thunderstorms in the vicinity of KSC during the summers of 1994 and 1995. These case studies reveal many intriguing aspects of cloud-to-ground, cloud-to-cloud, in-cloud, and cloud-to-air lightning discharges in relation to radar thunderstorm structure and evolution. They also enable the formulation of some preliminary working rules of potential use in the forecasting of initial and final ground strike threat. In addition, LDAR and LLP data sets from 1993 have been used to quantify the lightning threat relative to the center and edges of LDAR discharge patterns. Software has been written to overlay and display the various data sets as color imagery. However, human intervention is required to configure the data sets for proper intercomparison. Future efforts will involve additional software development to automate the data set intercomparisons, to display multiple overlay combinations in a windows format, and to allow for animation of the imagery. The software package will then be used as a tool to examine more fully the current cases and to explore additional cases in a timely manner. This will enable the formulation of more general and reliable forecasting guidelines and rules.

Forbes, Gregory S.↗
NASA NTRS2002

Implementation of Adaptive Digital Controllers on Programmable Logic Devices

Much has been made of the capabilities of Field Programmable Gate Arrays (FPGA's) in the hardware implementation of fast digital signal processing functions. Such capability also makes an FPGA a suitable platform for the digital implementation of closed loop controllers. Other researchers have implemented a variety of closed-loop digital controllers on FPGA's. Some of these controllers include the widely used Proportional-Integral-Derivative (PID) controller, state space controllers, neural network and fuzzy logic based controllers. There are myriad advantages to utilizing an FPGA for discrete-time control functions which include the capability for reconfiguration when SRAM- based FPGA's are employed, fast parallel implementation of multiple control loops and implementations that can meet space level radiation tolerance requirements in a compact form-factor. Generally, a software implementation on a Digital Signal Processor (DSP) device or microcontroller is used to implement digital controllers. At Marshall Space Flight Center, the Control Electronics Group has been studying adaptive discrete-time control of motor driven actuator systems using DSP devices. While small form factor, commercial DSP devices are now available with event capture, data conversion, Pulse Width Modulated (PWM) outputs and communication peripherals, these devices are not currently available in designs and packages which meet space level radiation requirements. In general, very few DSP devices are produced that are designed to meet any level of radiation tolerance or hardness. An alternative is required for compact implementation of such functionality to withstand the harsh environment encountered on spacemap. The goal of this effort is to create a fully digital, flight ready controller design that utilizes an FPGA for implementation of signal conditioning for control feedback signals, generation of commands to the controlled system, and hardware insertion of adaptive-control algorithm approaches. Radiation tolerant FPGA's are a feasible option for reaching this goal.

Gwaltney, David A.↗
NASA NTRS2005

Sensor Webs: Autonomous Rapid Response to Monitor Transient Science Events

To better understand how physical phenomena, such as volcanic eruptions, evolve over time, multiple sensor observations over the duration of the event are required. Using sensor web approaches that integrate original detections by in-situ sensors and global-coverage, lower-resolution, on-orbit assets with automated rapid response observations from high resolution sensors, more observations of significant events can be made with increased temporal, spatial, and spectral resolution. This paper describes experiments using Earth Observing 1 (EO-1) along with other space and ground assets to implement progressive mission autonomy to identify, locate and image with high resolution instruments phenomena such as wildfires, volcanoes, floods and ice breakup. The software that plans, schedules and controls the various satellite assets are used to form ad hoc constellations which enable collaborative autonomous image collections triggered by transient phenomena. This software is both flight and ground based and works in concert to run all of the required assets cohesively and includes software that is model-based, artificial intelligence software.

Mandl, Dan↗
NASA NTRS1986

Applications software supporting the Spartan Attitude Control System

The native software supporting a single mission for the Spartan Attitude Control System can require up to 40,000 lines of code. Most of this must be rewritten for each mission. Control system engineers use an array of Applications Software Packages residing in ground computers to write each mission's flight software. These Applications Packages are written in the 'C' programming language and run under the UNIX Operating System. This paper discusses each of the Attitude Control Applications Software Packages, and describes the purpose and design of each.

Stone, R. W.↗
NASA NTRS2002

Implementation of Adaptive Digital Controllers on Programmable Logic Devices

Much has been made of the capabilities of FPGA's (Field Programmable Gate Arrays) in the hardware implementation of fast digital signal processing. Such capability also makes an FPGA a suitable platform for the digital implementation of closed loop controllers. Other researchers have implemented a variety of closed-loop digital controllers on FPGA's. Some of these controllers include the widely used proportional-integral-derivative (PID) controller, state space controllers, neural network and fuzzy logic based controllers. There are myriad advantages to utilizing an FPGA for discrete-time control functions which include the capability for reconfiguration when SRAM-based FPGA's are employed, fast parallel implementation of multiple control loops and implementations that can meet space level radiation tolerance requirements in a compact form-factor. Generally, a software implementation on a DSP (Digital Signal Processor) or microcontroller is used to implement digital controllers. At Marshall Space Flight Center, the Control Electronics Group has been studying adaptive discrete-time control of motor driven actuator systems using digital signal processor (DSP) devices. While small form factor, commercial DSP devices are now available with event capture, data conversion, pulse width modulated (PWM) outputs and communication peripherals, these devices are not currently available in designs and packages which meet space level radiation requirements. In general, very few DSP devices are produced that are designed to meet any level of radiation tolerance or hardness. The goal of this effort is to create a fully digital, flight ready controller design that utilizes an FPGA for implementation of signal conditioning for control feedback signals, generation of commands to the controlled system, and hardware insertion of adaptive control algorithm approaches. An alternative is required for compact implementation of such functionality to withstand the harsh environment encountered on spacecraft. Radiation tolerant FPGA's are a feasible option for reaching this goal.

Gwaltney, David A.↗
DOE OSTI2020

Radiological Recovery Logistics Tool - 20161

Argonne is building and testing a tool, the Radiological Recovery Logistics Tool (RRLT), that can be used during the response and recovery from a radiological or nuclear incident to effectively allocate appropriate commercial and public works equipment to mitigate, remove, and contain radiological contamination. The requirements for this tool - as well as development of the resulting software - is overseen by a steering committee of stakeholders from DHS's National Urban Security Technology Laboratory (NUSTL), the Federal Emergency Management Agency (FEMA), and the Environmental Protection Agency (EPA). One essential requirement is for RRLT to support the efficient and appropriate allocation of resources for a radiological response. Subsequent discussions between ANL and stakeholders have solidified the nature of this support to include identification of the types of resources to be allocated. The study reported in this paper has both factored fundamental concepts and connections out of this identification process and created a Knowledge Base detailing support goals, response scenarios, and efficacy information on dozens of equipment types. In short, RRLT will dynamically apply these findings to situational conditions surrounding contamination incidents. RRLT's Domain, the model of elements, ideas and relationships with which the tool will work, draws concepts from technical reports and stakeholder vocabularies to connect response goals and scenarios to types of equipment that offer utility towards those goals in those scenarios. RRLT's Knowledge Base will contain details on dozens of equipment types and facilitate the operator's discovery and consumption of these details most pertinent to a dynamically selected subset of goals. The core of its Domain Model is based on a report authored by this team. This report [1] contains a comprehensive list of proposed equipment to accomplish various missions or scenarios that might arise after a large-scale radiological contamination incident in an urban environment or critical infrastructure. The report divides potential response and recovery efforts into five support goals: Survey and monitoring of the contaminated area; Mitigation of received dose to first responders: Decontamination (gross and final) of buildings, vehicles, roadways, parks, and other surfaces: Waste management of solid waste generated during recovery operations: and Containment of wastewater and other waste generated during the response and recovery phases. RRLT's development is driven by use cases. A use case is an intention with which a user approaches the software. Use cases are grouped into delivery increments to schedule development, testing, and presentation to stakeholders. This model partitions the system into seven increments: User Arrival and Authentication, Search and Navigation, Equipment Recommendation, Plan Management, Content Management, and Expanded Access. Once a user 15 authenticated, RRLT will present the user with a dashboard that allows them to explore or search RRLT's content. The dashboard will also include a 'Plan' panel for collecting decisions and relevant observations about an incident at hand to facilitate development of an equipment list. RRLT will offer three general modes of access to items in the knowledge base: - Keyword search for direct discovery of items, - Navigation along predetermined paths from recovery goal towards equipment types, and - Interactive guidance towards equipment types by an autonomous software agent: the Equipment Recommendation Wizard. This presentation will detail progress in the development of the RRLT and also discuss opportunities for those interested in providing feedback on its content and functionality. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
NASA NTRS1976

Software handlers for process interfaces

Process interfaces are developed in an effort to reduce the time, effort, and money required to install computer systems. Probably the chief obstacle to the achievement of these goals lies in the problem of developing software handlers having the same degree of generality and modularity as the hardware. The problem of combining the advantages of modular instrumentation with those of modern multitask operating systems has not been completely solved, but there are a number of promising developments. The essential principles involved are considered.

Bercaw, R. W.↗
NASA NTRS2003

IPG Job Manager v2.0 Design Documentation

This viewgraph presentation provides a high-level design of the IPG Job Manager, and satisfies its Master Requirement Specification v2.0 Revision 1.0, 01/29/2003. The presentation includes a Software Architecture/Functional Overview with the following: Job Model; Job Manager Client/Server Architecture; Job Manager Client (Job Manager Client Class Diagram and Job Manager Client Activity Diagram); Job Manager Server (Job Manager Client Class Diagram and Job Manager Client Activity Diagram); Development Environment; Project Plan; Requirement Traceability.

Hu, Chaumin↗
NASA NTRS1990

A software system for laser design and analysis

A laser-material database and laser-modeling software system for designing lasers for laser-based Light Detection And Ranging (LIDAR) systems are presented. The software system consists of three basic sections: the database, laser models, and interface software. The database contains the physical parameters of laser, optical, and nonlinear materials required by laser models. The models include efficiency calculations, electrooptical component models, resonator, amplifier, and oscillator models, and miscellaneous models. The interface software provides a user-friendly interface between the user and his personal data files, the database, and models. The structure of the software system is essentially in place, while future plans call for upgrading the computer hardware and software in order to support a multiuser multitask environment.

Cross, P. L.↗
NASA NTRS2010

Fundamental Travel Demand Model Example

Instances of transportation models are abundant and detailed "how to" instruction is available in the form of transportation software help documentation. The purpose of this paper is to look at the fundamental inputs required to build a transportation model by developing an example passenger travel demand model. The example model reduces the scale to a manageable size for the purpose of illustrating the data collection and analysis required before the first step of the model begins. This aspect of the model development would not reasonably be discussed in software help documentation (it is assumed the model developer comes prepared). Recommendations are derived from the example passenger travel demand model to suggest future work regarding the data collection and analysis required for a freight travel demand model.

Hanssen, Joel↗
NASA NTRS1982

Shuttle automatic landing system

The Shuttle automatic landing system design requirements are discussed, the approach and landing flight phase is described, and the hardware and software subsystems are functionally described. Emphasis is placed on the complexity, flexibility, and criticality of the software function. The software structure, critical computational problems, and verification process as a subsystem are discussed. Finally, the hardware/software verification activities required before flight test of the autoland system are described, along with the results from two flight tests and the planned system certification to the operational flight boundaries.

Tsikalas, G.↗
NASA NTRS1993

The application of automated operations at the Institutional Processing Center

The JPL Institutional and Mission Computing Division, Communications, Computing and Network Services Section, with its mission contractor, OAO Corporation, have for some time been applying automation to the operation of JPL's Information Processing Center (IPC). Automation does not come in one easy to use package. Automation for a data processing center is made up of many different software and hardware products supported by trained personnel. The IPC automation effort formally began with console automation, and has since spiraled out to include production scheduling, data entry, report distribution, online reporting, failure reporting and resolution, documentation, library storage, and operator and user education, while requiring the interaction of multi-vendor and locally developed software. To begin the process, automation goals are determined. Then a team including operations personnel is formed to research and evaluate available options. By acquiring knowledge of current products and those in development, taking an active role in industry organizations, and learning of other data center's experiences, a forecast can be developed as to what direction technology is moving. With IPC management's approval, an implementation plan is developed and resources identified to test or implement new systems. As an example, IPC's new automated data entry system was researched by Data Entry, Production Control, and Advance Planning personnel. A proposal was then submitted to management for review. A determination to implement the new system was made and elements/personnel involved with the initial planning performed the implementation. The final steps of the implementation were educating data entry personnel in the areas effected and procedural changes necessary to the successful operation of the new system.

Barr, Thomas H.↗
NASA NTRS2004

Robust Requirements Tracing via Internet Search Technology: Improving an IV and V Technique

There are three major objectives to this phase of the work. (1) Improvement of Information Retrieval (IR) methods for Independent Verification and Validation (IV&V) requirements tracing. Information Retrieval methods are typically developed for very large (order of millions - tens of millions and more documents) document collections and therefore, most successfully used methods somewhat sacrifice precision and recall in order to achieve efficiency. At the same time typical IR systems treat all user queries as independent of each other and assume that relevance of documents to queries is subjective for each user. The IV&V requirements tracing problem has a much smaller data set to operate on, even for large software development projects; the set of queries is predetermined by the high-level specification document and individual requirements considered as query input to IR methods are not necessarily independent from each other. Namely, knowledge about the links for one requirement may be helpful in determining the links of another requirement. Finally, while the final decision on the exact form of the traceability matrix still belongs to the IV&V analyst, his/her decisions are much less arbitrary than those of an Internet search engine user. All this suggests that the information available to us in the framework of the IV&V tracing problem can be successfully leveraged to enhance standard IR techniques, which in turn would lead to increased recall and precision. We developed several new methods during Phase II; (2) IV&V requirements tracing IR toolkit. Based on the methods developed in Phase I and their improvements developed in Phase II, we built a toolkit of IR methods for IV&V requirements tracing. The toolkit has been integrated, at the data level, with SAIC's SuperTracePlus (STP) tool; (3) Toolkit testing. We tested the methods included in the IV&V requirements tracing IR toolkit on a number of projects.

Hayes, Jane↗
NASA NTRS1985

Space Station data system analysis/architecture study. Task 1: Functional requirements definition, DR-5

The initial task in the Space Station Data System (SSDS) Analysis/Architecture Study is the definition of the functional and key performance requirements for the SSDS. The SSDS is the set of hardware and software, both on the ground and in space, that provides the basic data management services for Space Station customers and systems. The primary purpose of the requirements development activity was to provide a coordinated, documented requirements set as a basis for the system definition of the SSDS and for other subsequent study activities. These requirements should also prove useful to other Space Station activities in that they provide an indication of the scope of the information services and systems that will be needed in the Space Station program. The major results of the requirements development task are as follows: (1) identification of a conceptual topology and architecture for the end-to-end Space Station Information Systems (SSIS); (2) development of a complete set of functional requirements and design drivers for the SSIS; (3) development of functional requirements and key performance requirements for the Space Station Data System (SSDS); and (4) definition of an operating concept for the SSIS. The operating concept was developed both from a Space Station payload customer and operator perspective in order to allow a requirements practicality assessment.

Source record↗
NASA NTRS1985

ENCOMPASS: A SAGA based environment for the compositon of programs and specifications, appendix A

ENCOMPASS is an example integrated software engineering environment being constructed by the SAGA project. ENCOMPASS supports the specification, design, construction and maintenance of efficient, validated, and verified programs in a modular programming language. The life cycle paradigm, schema of software configurations, and hierarchical library structure used by ENCOMPASS is presented. In ENCOMPASS, the software life cycle is viewed as a sequence of developments, each of which reuses components from the previous ones. Each development proceeds through the phases planning, requirements definition, validation, design, implementation, and system integration. The components in a software system are modeled as entities which have relationships between them. An entity may have different versions and different views of the same project are allowed. The simple entities supported by ENCOMPASS may be combined into modules which may be collected into projects. ENCOMPASS supports multiple programmers and projects using a hierarchical library system containing a workspace for each programmer; a project library for each project, and a global library common to all projects.

Terwilliger, Robert B.↗