Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “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 397 records · Page 22
All sourcesNASA NTRSDOE OSTI
NASA NTRS2001

Fast Formal Analysis of Requirements via "Topoi Diagrams"

Early testing of requirements can decrease the cost of removing errors in software projects. However, unless done carefully, that testing process can significantly add to the cost of requirements analysis. We show here that requirements expressed as topoi diagrams can be built and tested cheaply using our SP2 algorithm, the formal temporal properties of a large class of topoi can be proven very quickly, in time nearly linear in the number of nodes and edges in the diagram. There are two limitations to our approach. Firstly, topoi diagrams cannot express certain complex concepts such as iteration and sub-routine calls. Hence, our approach is more useful for requirements engineering than for traditional model checking domains. Secondly, out approach is better for exploring the temporal occurrence of properties than the temporal ordering of properties. Within these restrictions, we can express a useful range of concepts currently seen in requirements engineering, and a wide range of interesting temporal properties.

Menzies, Tim↗
NASA NTRS2002

Analytical/Operational Requirements for the In Situ Chemical Analysis of Cometary and Planetary Environments Using GC-IMS

Exobiology flight experiments require highly sensitive instrumentation for the in situ analysis of the volatile chemical species that occur in the atmospheres and surfaces of various bodies within the solar system. The complex mixtures encountered place a heavy burden on the analytical instrumentation to detect and identify all species present. The minimal resources available onboard for such missions mandate that the instruments provide maximum analytical capabilities with minimal requirements of volume, weight and consumables. The miniCIDEX instrument was developed for the chemical analysis of a cemetery environment. It combined a Gas Chromatograph (GC) with a helium based Ion Mobility Spectrometer (IMS) to fulfill the analytical requirements of a cemetery exobiology mission: universal response; ppb sensitivity; low mass, volume and consumable MiniCIDEX is now a candidate for the chemical analysis instrument of a Titan Aero-rover Mission. The complexity of the analyses will be similar to the comet application with a heavier emphasis on organic molecules. Because the Titan Aero-Rover will be a balloon powered rover, much more attention is placed on the total mass of the instrument package. The GC will likely be a Micro-Electro-Mechanical-System (MEMS) design, smaller than the initial miniCIDEX GC by a factor of ten (with a similar reduction in consumable use). Similar miniaturization of the helium-based IMS will be necessary while maintaining the analytical capabilities. The two mission applications, the analytical requirements, and the evolution of the IMS design to accommodate these requirements will be presented.

Kojiro, Daniel R.↗
NASA NTRS2002

Inter-Satellite Communications Considerations and Requirements for Distributed Spacecraft and Formation Flying Systems

In order to avoid selecting inadequate inter-spacecraft cross-link communications standards for Distributed Spacecraft System (DSS) missions, it is first necessary to identify cross-link communications strategies and requirements common to a cross-section of proposed missions. This paper addresses the cross-link communication strategies and requirements derived from a survey of 39 DSS mission descriptions that are projected for potential launch within the next 20 years. The inter-spacecraft communications strategies presented are derived from the topological and communications constraints from the DSS missions surveyed. Basic functional requirements are derived from an analysis of the fundamental activities that must be undertaken to establish and maintain a cross-link between two DSS spacecraft. Cross-link bandwidth requirements are derived from high-level assessments of mission science objectives and operations concepts. Finally, a preliminary assessment of possible cross-link standards is presented within the context of the basic operational and interoperability requirements.

Kwadrat, Carl F.↗
NASA NTRS2003

Initial SVS Integrated Technology Evaluation Flight Test Requirements and Hardware Architecture

This document presents the flight test requirements for the Initial Synthetic Vision Systems Integrated Technology Evaluation flight Test to be flown aboard NASA Langley's ARIES aircraft and the final hardware architecture implemented to meet these requirements. Part I of this document contains the hardware, software, simulator, and flight operations requirements for this light test as they were defined in August 2002. The contents of this section are the actual requirements document that was signed for this flight test. Part II of this document contains information pertaining to the hardware architecture that was realized to meet these requirements as presented to and approved by a Critical Design Review Panel prior to installation on the B-757 Airborne Research Integrated Experiments Systems (ARIES) airplane. This information includes a description of the equipment, block diagrams of the architecture, layouts of the workstations, and pictures of the actual installations.

Harrison, Stella V.↗
NASA NTRS2002

Solid Waste Management Requirements Definition for Advanced Life Support Missions: Results

Prior to determining what Solid Waste Management (SWM) technologies should be researched and developed by the Advanced Life Support (ALS) Project for future missions, there is a need to define SWM requirements. Because future waste streams will be highly mission-dependent, missions need to be defined prior to developing SWM requirements. The SWM Working Group has used the mission architecture outlined in the System Integration, Modeling and Analysis (SIMA) Element Reference Missions Document (RMD) as a starting point in the requirement development process. The missions examined include the International Space Station (ISS), a Mars Dual Lander mission, and a Mars Base. The SWM Element has also identified common SWM functionalities needed for future missions. These functionalities include: acceptance, transport, processing, storage, monitoring and control, and disposal. Requirements in each of these six areas are currently being developed for the selected missions. This paper reviews the results of this ongoing effort and identifies mission-dependent resource recovery requirements.

Alazraki, Michael P.↗
NASA NTRS2004

S&MA Requirements Tool (SMART)

In FY03 QS10 began building an S&MA web based data management tool,"Safety & Mission Assurance Requirements Tool" (SMART) that identifies S&MA requirements, tailors requirements to IAW project/program categories, tracks implementation, and provides a template for developing requirements and tracking waivers. This report provides a SMART process flow, typical application, typical data requirement deliverables, progress in 03, and FY04 activities.

Kulpa, Vyga↗
NASA NTRS2005

Cognitive Functioning in Space Exploration Missions: A Human Requirement

Solving cognitive issues in the exploration missions will require implementing results from both Human Behavior and Performance, and Space Human Factors Engineering. Operational and research cognitive requirements need to reflect a coordinated management approach with appropriate oversight and guidance from NASA headquarters. First, this paper will discuss one proposed management method that would combine the resources of Space Medicine and Space Human Factors Engineering at JSC, other NASA agencies, the National Space Biomedical Research Institute, Wyle Labs, and other academic or industrial partners. The proposed management is based on a Human Centered Design that advocates full acceptance of the human as a system equal to other systems. Like other systems, the human is a system with many subsystems, each of which has strengths and limitations. Second, this paper will suggest ways to inform exploration policy about what is needed for optimal cognitive functioning of the astronaut crew, as well as requirements to ensure necessary assessment and intervention strategies for the human system if human limitations are reached. Assessment strategies will include clinical evaluation and fitness-to-perform evaluations. Clinical intervention tools and procedures will be available to the astronaut and space flight physician. Cognitive performance will be supported through systematic function allocation, task design, training, and scheduling. Human factors requirements and guidelines will lead to well-designed information displays and retrieval systems that reduce crew time and errors. Means of capturing process, design, and operational requirements to ensure crew performance will be discussed. Third, this paper will describe the current plan of action, and future challenges to be resolved before a lunar or Mars expedition. The presentation will include a proposed management plan for research, involvement of various organizations, and a timetable of deliverables.

Fiedler, Edan↗
NASA NTRS2006

Questioning the Role of Requirements Engineering in the Causes of Safety-Critical Software Failures

Many software failures stem from inadequate requirements engineering. This view has been supported both by detailed accident investigations and by a number of empirical studies; however, such investigations can be misleading. It is often difficult to distinguish between failures in requirements engineering and problems elsewhere in the software development lifecycle. Further pitfalls arise from the assumption that inadequate requirements engineering is a cause of all software related accidents for which the system fails to meet its requirements. This paper identifies some of the problems that have arisen from an undue focus on the role of requirements engineering in the causes of major accidents. The intention is to provoke further debate within the emerging field of forensic software engineering.

Johnson, C. W.↗
NASA NTRS2004

State analysis requirements database for engineering complex embedded systems

It has become clear that spacecraft system complexity is reaching a threshold where customary methods of control are no longer affordable or sufficiently reliable. At the heart of this problem are the conventional approaches to systems and software engineering based on subsystem-level functional decomposition, which fail to scale in the tangled web of interactions typically encountered in complex spacecraft designs. Furthermore, there is a fundamental gap between the requirements on software specified by systems engineers and the implementation of these requirements by software engineers. Software engineers must perform the translation of requirements into software code, hoping to accurately capture the systems engineer's understanding of the system behavior, which is not always explicitly specified. This gap opens up the possibility for misinterpretation of the systems engineer's intent, potentially leading to software errors. This problem is addressed by a systems engineering tool called the State Analysis Database, which provides a tool for capturing system and software requirements in the form of explicit models. This paper describes how requirements for complex aerospace systems can be developed using the State Analysis Database.

model base engineering↗
NASA NTRS2007

High Altitude Long Endurance UAV Analysis of Alternatives and Technology Requirements Development

An Analysis of Alternatives and a Technology Requirements Study were conducted for two mission areas utilizing various types of High Altitude Long Endurance (HALE) Unmanned Aerial Vehicles (UAV). A hurricane science mission and a communications relay mission provided air vehicle requirements which were used to derive sixteen potential HALE UAV configurations, including heavier-than-air (HTA) and lighter-than-air (LTA) concepts with both consumable fuel and solar regenerative propulsion systems. A HTA diesel-fueled wing-body-tail configuration emerged as the preferred concept given near-term technology constraints. The cost effectiveness analysis showed that simply maximizing vehicle endurance can be a sub-optimum system solution. In addition, the HTA solar regenerative configuration was utilized to perform both a mission requirements study and a technology development study. Given near-term technology constraints, the solar regenerative powered vehicle was limited to operations during the long days and short nights at higher latitudes during the summer months. Technology improvements are required in energy storage system specific energy and solar cell efficiency, along with airframe drag and mass reductions to enable the solar regenerative vehicle to meet the full mission requirements.

Nickol, Craig L.↗
NASA NTRS2008

Using Life-Cycle Human Factors Engineering to Avoid $2.4 Million in Costs: Lessons Learned from NASA's Requirements Verification Process for Space Payloads

The Human Factors Implementation Team (HFIT) process has been used to verify human factors requirements for NASA International Space Station (ISS) payloads since 2003, resulting in $2.4 million in avoided costs. This cost benefit has been realized by greatly reducing the need to process time-consuming formal waivers (exceptions) for individual requirements violations. The HFIT team, which includes astronauts and their technical staff, acts as the single source for human factors requirements integration of payloads. HFIT has the authority to provide inputs during early design phases, thus eliminating many potential requirements violations in a cost-effective manner. In those instances where it is not economically or technically feasible to meet the precise metric of a given requirement, HFIT can work with the payload engineers to develop common sense solutions and formally document that the resulting payload design does not materially affect the astronaut s ability to operate and interact with the payload. The HFIT process is fully ISO 9000 compliant and works concurrently with NASA s formal systems engineering work flow. Due to its success with payloads, the HFIT process is being adapted and extended to ISS systems hardware. Key aspects of this process are also being considered for NASA's Space Shuttle replacement, the Crew Exploration Vehicle.

Carr, Daniel↗
NASA NTRS2005

Recommendations for UAS Crew Ratings. Pilot Ratings and Authorization Requirements for UAS

This position paper is intended to recommend the minimum certificate and rating requirements for a pilot to operate an Unmanned Aircraft System (UAS) in the National Airspace System. The paper will recommend the minimum requirements based on the Knowledge, Skills, and Abilities (KSA) required of a UAS pilot and show how those compare to the KSAs required by regulation for manned-aircraft pilots. The paper will provide substantiation based on studies conducted using analyses, simulation and flight experience. The paper is not yet complete; only initial working material is included. The material provided describes the body of work completed thus far and the plan for remaining tasks to complete the recommendation. The HSI Pilot KSA document provides an analysis of the knowledge, skills, and abilities required for UAS operation in the NAS. It is the source document used for the position paper.

Source record↗
NASA NTRS2005

Step 1: Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Command, Control, and Communications (C3)

The document provides the Human System Integration(HSI) high-level functional C3 HSI requirements for the interface to the pilot. Description includes (1) the information required by the pilot to have knowledge C3 system status, and (2) the control capability needed by the pilot to obtain C3 information. Fundamentally, these requirements provide the candidate C3 technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how C3 operations and functions should interface with the pilot to provide the necessary C3 functionality to the UA-pilot system. Requirements and guidelines for C3 are partitioned into three categories: (1) Pilot-Air Traffic Control (ATC) Voice Communications (2) Pilot-ATC Data Communications, and (3) command and control of the unmanned aircraft (UA). Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗
NASA NTRS2007

Weather Requirements and Procedures for Step 1: High Altitude Long Endurance (HALE) Unmanned Aircraft System (UAS) Flight Operations in the National Air Space (NAS)

This cover sheet is for version 2 of the weather requirements document along with Appendix A. The purpose of the requirements document was to identify and to list the weather functional requirements needed to achieve the Access 5 vision of "operating High Altitude, Long Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the National Airspace System (NAS) for Step 1." A discussion of the Federal Aviation Administration (FAA) references and related policies, procedures, and standards is provided as basis for the recommendations supported within this document. Additional procedures and reference documentation related to weather functional requirements is also provided for background. The functional requirements and related information are to be proposed to the FAA and various standards organizations for consideration and approval. The appendix was designed to show that sources of flight weather information are readily available to UAS pilots conducting missions in the NAS. All weather information for this presentation was obtained from the public internet.

Source record↗
NASA NTRS2008

Information Requirements for Supervisory Air Traffic Controllers in Support of a Wake Vortex Departure System

Closely Space Parallel Runway (CSPR) configurations are capacity limited for departures due to the requirement to apply wake vortex separation standards from traffic departing on the adjacent parallel runway. To mitigate the effects of this constraint, a concept focusing on wind dependent departure operations has been developed, known as the Wake Turbulence Mitigation for Departures (WTMD). This concept takes advantage of the fact that crosswinds of sufficient velocity blow wakes generated by aircraft departing from the downwind runway away from the upwind runway. Consequently, under certain conditions, wake separations on the upwind runway would not be required based on wakes generated by aircraft on the downwind runway, as is currently the case. It follows that information requirements, and sources for this information, would need to be determined for airport traffic control tower (ATCT) supervisory personnel who would be charged with decisions regarding use of the procedure. To determine the information requirements, data were collected from ATCT supervisors and controller-in-charge qualified individuals at Lambert-St. Louis International Airport (STL) and George Bush Houston Intercontinental Airport (IAH). STL and IAH were chosen as data collection sites based on the implementation of a WTMD prototype system, operating in shadow mode, at these locations. The 17 total subjects (STL: 5, IAH: 12) represented a broad-base of air traffic experience. Results indicated that the following information was required to support the conduct of WTMD operations: current and forecast weather information, current and forecast traffic demand and traffic flow restrictions, and WTMD System status information and alerting. Subjects further indicated that the requisite information is currently available in the tower cab with the exception of the WTMD status and alerting. Subjects were given a demonstration of a display supporting the prototype systems and unanimously stated that the WTMD status information they felt important was represented. Overwhelmingly, subjects felt that approving, monitoring and terminating the WTMD procedure could be integrated into their supervisory workload.

Lohr, Gary W.↗
NASA NTRS2009

A Method for and Issues Associated with the Determination of Space Suit Joint Requirements

In the design of a new space suit it is necessary to have requirements that define what mobility space suit joints should be capable of achieving in both a system and at the component level. NASA elected to divide mobility into its constituent parts-range of motion (ROM) and torque- in an effort to develop clean design requirements that limit subject performance bias and are easily verified. Unfortunately, the measurement of mobility can be difficult to obtain. Current technologies, such as the Vicon motion capture system, allow for the relatively easy benchmarking of range of motion (ROM) for a wide array of space suit systems. The ROM evaluations require subjects in the suit to accurately evaluate the ranges humans can achieve in the suit. However, when it comes to torque, there are significant challenges for both benchmarking current performance and writing requirements for future suits. This is reflected in the fact that torque definitions have been applied to very few types of space suits and with limited success in defining all the joints accurately. This paper discussed the advantages and disadvantages to historical joint torque evaluation methods, describes more recent efforts directed at benchmarking joint torques of prototype space suits, and provides an outline for how NASA intends to address joint torque in design requirements for the Constellation Space Suit System (CSSS).

Matty, Jennifer E.↗
NASA NTRS2010

Coverage Metrics for Requirements-Based Testing: Evaluation of Effectiveness

In black-box testing, the tester creates a set of tests to exercise a system under test without regard to the internal structure of the system. Generally, no objective metric is used to measure the adequacy of black-box tests. In recent work, we have proposed three requirements coverage metrics, allowing testers to objectively measure the adequacy of a black-box test suite with respect to a set of requirements formalized as Linear Temporal Logic (LTL) properties. In this report, we evaluate the effectiveness of these coverage metrics with respect to fault finding. Specifically, we conduct an empirical study to investigate two questions: (1) do test suites satisfying a requirements coverage metric provide better fault finding than randomly generated test suites of approximately the same size?, and (2) do test suites satisfying a more rigorous requirements coverage metric provide better fault finding than test suites satisfying a less rigorous requirements coverage metric? Our results indicate (1) only one coverage metric proposed -- Unique First Cause (UFC) coverage -- is sufficiently rigorous to ensure test suites satisfying the metric outperform randomly generated test suites of similar size and (2) that test suites satisfying more rigorous coverage metrics provide better fault finding than test suites satisfying less rigorous coverage metrics.

Staats, Matt↗
NASA NTRS2010

Automated Derivation of Complex System Constraints from User Requirements

The Payload Operations Integration Center (POIC) located at the Marshall Space Flight Center has the responsibility of integrating US payload science requirements for the International Space Station (ISS). All payload operations must request ISS system resources so that the resource usage will be included in the ISS on-board execution timelines. The scheduling of resources and building of the timeline is performed using the Consolidated Planning System (CPS). The ISS resources are quite complex due to the large number of components that must be accounted for. The planners at the POIC simplify the process for Payload Developers (PD) by providing the PDs with a application that has the basic functionality PDs need as well as list of simplified resources in the User Requirements Collection (URC) application. The planners maintained a mapping of the URC resources to the CPS resources. The process of manually converting PD's science requirements from a simplified representation to a more complex CPS representation is a time-consuming and tedious process. The goal is to provide a software solution to allow the planners to build a mapping of the complex CPS constraints to the basic URC constraints and automatically convert the PD's requirements into systems requirements during export to CPS.

Foshee, Mark↗