Search NASA⌕ Search

SEARCH · Search NASA

Results for “Requirements Verification”

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 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

NTP comparison process

The systems engineering process for the concept definition phase of the program involves requirements definition, system definition, and consistent concept definition. The requirements definition process involves obtaining a complete understanding of the system requirements based on customer needs, mission scenarios, and nuclear thermal propulsion (NTP) operating characteristics. A system functional analysis is performed to provide a comprehensive traceability and verification of top-level requirements down to detailed system specifications and provides significant insight into the measures of system effectiveness to be utilized in system evaluation. The second key element in the process is the definition of system concepts to meet the requirements. This part of the process involves engine system and reactor contractor teams to develop alternative NTP system concepts that can be evaluated against specific attributes, as well as a reference configuration against which to compare system benefits and merits. Quality function deployment (QFD), as an excellent tool within Total Quality Management (TQM) techniques, can provide the required structure and provide a link to the voice of the customer in establishing critical system qualities and their relationships. The third element of the process is the consistent performance comparison. The comparison process involves validating developed concept data and quantifying system merits through analysis, computer modeling, simulation, and rapid prototyping of the proposed high risk NTP subsystems. The maximum amount possible of quantitative data will be developed and/or validated to be utilized in the QFD evaluation matrix. If upon evaluation of a new concept or its associated subsystems determine to have substantial merit, those features will be incorporated into the reference configuration for subsequent system definition and comparison efforts.

Corban, Robert↗
NASA NTRS2021

Vertiport Automation Software Architecture and Requirements

The purpose of Vertiport Automation Software Architecture and Requirements was developed to mature the Vertiport Automation System (VAS) described in the High-Density Automated Vertiport ConOps, into a set of artifacts that enable the development of a VAS prototype. The scope of document was to develop: (1) A VAS Software Architecture diagram that logically organizes VAS functionality into specific software components; (2) VAS Software Trade Study identifying existing commercial products and NASA research that can be used in part or with modifications to fulfill VAS functionality. (3) A set of VAS Functional Requirements which decompose the VAS concept into software functionality, including any interfaces and data flows needed; (4) A set of VAS Test Approaches describing a methodology for verification of the VAS Functional Requirements; and (5) An application user experience (UX) design study describing the general features needed in a VAS user interface.

Advanced Air Mobility↗
NASA NTRS1992

Lunar base mission technology issues and orbital demonstration requirements on space station

The International Space Station has been the object of considerable design, redesign, and alteration since it was originally proposed in early 1984. In the intervening years the station has slowly evolved to a specific design that was thoroughly reviewed by a large agency-wide Critical Evaluation Task Force (CETF). As space station designs continue to evolve, studies must be conducted to determine the suitability of the current design for some of the primary purposes for which the station will be used. This paper concentrates on the technology requirements and issues, the on-orbit demonstration and verification program, and the space station focused support required prior to the establishment of a permanently manned lunar base as identified in the National Commission on Space report. Technology issues associated with the on-orbit assembly and processing of the lunar vehicle flight elements are also discussed.

Llewellyn, Charles P.↗
NASA NTRS2003

Enhancing the Human Factors Engineering Role in an Austere Fiscal Environment

An austere fiscal environment in the aerospace community creates pressures to reduce program costs, often minimizing or sometimes even deleting the human interface requirements from the design process. With an assumption that the flight crew can recover real time from a poorly human factored space vehicle design, the classical crew interface requirements have been either not included in the design or not properly funded, though carried as requirements. Cost cuts have also affected quality of retained human factors engineering personnel. In response to this concern, planning is ongoing to correct the acting issues. Herein are techniques for ensuring that human interface requirements are integrated into a flight design, from proposal through verification and launch activation. This includes human factors requirements refinement and consolidation across flight programs; keyword phrases in the proposals; closer ties with systems engineering and other classical disciplines; early planning for crew-interface verification; and an Agency integrated human factors verification program, under the One NASA theme. Importance is given to communication within the aerospace human factors discipline, and utilizing the strengths of all government, industry, and academic human factors organizations in an unified research and engineering approach. A list of recommendations and concerns are provided in closing.

Stokes, Jack W.↗
NASA NTRS1984

Capture of uncontrolled satellites - A flight demonstration

NASA is presently exploring concepts, systems, and devices for capturing uncontrolled or non-operational satellites. Understanding of this type capture involves development of requirements and options, analyses of approaches, and extensive ground simulations. The verification of an approach is expected to require flight demonstrations of the concepts and hardware to assure confidence in application. This paper addresses a flight demonstration involving the Shuttle, an Orbital Maneuvering Vehicle (OMV), a capture mechanism, and a target vehicle capable of providing characteristic motion. A mission scenario is projected which demonstrates a capture concept, mission sequencing, capture vehicle potential, and overall capture possibilities with man-in-the-loop control. The proposed demonstration is considered a stepping stone to more demanding capture requirements. On-orbit activities are deliberately constrained to existing technology and projected systems and hardware capability for the year 1990.

Lenox, H. M.↗
DOE OSTI2025

Data for NB6 HBRR Science Design ORNL/TM-2025/3807

Data for the report (ORNL/TM-2025/3807) that describes the calculations and the Monte Carlo Ray Tracing simulations performed using the McStas package to determine the coatings and geometry for the NB-6 guide. It provides the information to inform the mechanical design, validation tests and verification that it meets the science requirements.

47 OTHER INSTRUMENTATION↗
NASA NTRS1987

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

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

Tamayo, Tak Chai↗
NASA NTRS1992

Structural verification for GAS experiments

The purpose of this paper is to assist the Get Away Special (GAS) experimenter in conducting a thorough structural verification of its experiment structural configuration, thus expediting the structural review/approval process and the safety process in general. Material selection for structural subsystems will be covered with an emphasis on fasteners (GSFC fastener integrity requirements) and primary support structures (Stress Corrosion Cracking requirements and National Space Transportation System (NSTS) requirements). Different approaches to structural verifications (tests and analyses) will be outlined especially those stemming from lessons learned on load and fundamental frequency verification. In addition, fracture control will be covered for those payloads that utilize a door assembly or modify the containment provided by the standard GAS Experiment Mounting Plate (EMP). Structural hazard assessment and the preparation of structural hazard reports will be reviewed to form a summation of structural safety issues for inclusion in the safety data package.

Peden, Mark Daniel↗
NASA NTRS2013

Towards Requirements in Systems Engineering for Aerospace IVHM Design

Health management (HM) technologies have been employed for safety critical system for decades, but a coherent systematic process to integrate HM into the system design is not yet clear. Consequently, in most cases, health management resorts to be an after-thought or 'band-aid' solution. Moreover, limited guidance exists for carrying out systems engineering (SE) on the subject of writing requirements for designs with integrated vehicle health management (IVHM). It is well accepted that requirements are key to developing a successful IVHM system right from the concept stage to development, verification, utilization, and support. However, writing requirements for systems with IVHM capability have unique challenges that require the designers to look beyond their own domains and consider the constraints and specifications of other interlinked systems. In this paper we look at various stages in the SE process and identify activities specific to IVHM design and development. More importantly, several relevant questions are posed that system engineers must address at various design and development stages. Addressing these questions should provide some guidance to systems engineers towards writing IVHM related requirements to ensure that appropriate IVHM functions are built into the system design.

Requirements↗
NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, attitude control, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on previous missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the perceived benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗
NASA NTRS1984

Payload crew training complex simulation engineer's handbook

The Simulation Engineer's Handbook is a guide for new engineers assigned to Experiment Simulation and a reference for engineers previously assigned. The experiment simulation process, development of experiment simulator requirements, development of experiment simulator hardware and software, and the verification of experiment simulators are discussed. The training required for experiment simulation is extensive and is only referenced in the handbook.

Shipman, D. L.↗
NASA NTRS1988

Automatic programming for critical applications

The important phases of a software life cycle include verification and maintenance. Usually, the execution performance is an expected requirement in a software development process. Unfortunately, the verification and the maintenance of programs are the time consuming and the frustrating aspects of software engineering. The verification cannot be waived for the programs used for critical applications such as, military, space, and nuclear plants. As a consequence, synthesis of programs from specifications, an alternative way of developing correct programs, is becoming popular. The definition, or what is understood by automatic programming, has been changed with our expectations. At present, the goal of automatic programming is the automation of programming process. Specifically, it means the application of artificial intelligence to software engineering in order to define techniques and create environments that help in the creation of high level programs. The automatic programming process may be divided into two phases: the problem acquisition phase and the program synthesis phase. In the problem acquisition phase, an informal specification of the problem is transformed into an unambiguous specification while in the program synthesis phase such a specification is further transformed into a concrete, executable program.

Loganantharaj, Raj L.↗
NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, knowledge of attitude control, and attitude control hardware, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on other missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗
NASA NTRS2016

Integrating MBSE into Ongoing Projects: Requirements Validation and Test Planning for the ISS SAFER

The International Space Station (ISS) Simplified Aid for Extra Vehicular Activity (EVA) Rescue (SAFER) is the spacewalking astronaut's final safety measure against separating from the ISS and being unable to return safely. Since the late 1990s, the SAFER has been a standard element of the spacewalking astronaut's equipment. The ISS SAFER project was chartered to develop a new block of SAFER units using a highly similar design to the legacy SAFER (known as the USA SAFER). An on-orbit test module was also included in the project to enable periodic maintenance/propulsion system checkout on the ISS SAFER. On the ISS SAFER project, model-based systems engineering (MBSE) was not the initial systems engineering (SE) approach, given the volume of heritage systems engineering and integration (SE&I) products. The initial emphasis was ensuring traceability to ISS program standards as well as to legacy USA SAFER requirements. The requirements management capabilities of the Cradle systems engineering tool were to be utilized to that end. During development, however, MBSE approaches were applied selectively to address specific challenges in requirements validation and test and verification (T&V) planning, which provided measurable efficiencies to the project. From an MBSE perspective, ISS SAFER development presented a challenge and an opportunity. Addressing the challenge first, the project was tasked to use the original USA SAFER operational and design requirements baseline, with a number of additional ISS program requirements to address evolving certification expectations for systems operating on the ISS. Additionally, a need to redesign the ISS SAFER avionics architecture resulted in a set of changes to the design requirements baseline. Finally, the project added an entirely new functionality for on-orbit maintenance. After initial requirements integration, the system requirements count was approaching 1000, which represented a growth of 4x over the original USA SAFER system. This presented the challenge - How to confirm that this new set of requirements set would result in the creation of the desired capability.

Anderson, Herbert A.↗
NASA NTRS2015

Proposal for a Sample Pilot Response Model

Regulations to establish operational and performance requirements for unmanned aircraft systems (UAS) are being developed by a consortium of government, industry and academic institutions. Those requirements will apply to the new detect and avoid (DAA) systems and other equipment necessary to integrate UAS with the National Airspace System (NAS) and are determined according to their contribution to the overall safety case for such an integration. In order to perform end-to-end verification and validation of DAA requirements, a committee accepted pilot response model is needed to emulate UAS pilots in closed-loop Monte Carlo fast-time simulations. This briefing focuses on background of the pilot model used in previous Airspace Concept Evaluation System studies, identification of strengths and weaknesses in that model, and proposals on model improvements. The briefing also looks to build consensus around a common architecture and assumptions for modeling the pilot for UAS DAA systems.

Santiago, Confesor↗
NASA NTRS2010

Validation and Verification of Future Integrated Safety-Critical Systems Operating under Off-Nominal Conditions

Loss of control remains one of the largest contributors to aircraft fatal accidents worldwide. Aircraft loss-of-control accidents are highly complex in that they can result from numerous causal and contributing factors acting alone or (more often) in combination. Hence, there is no single intervention strategy to prevent these accidents and reducing them will require a holistic integrated intervention capability. Future onboard integrated system technologies developed for preventing loss of vehicle control accidents must be able to assure safe operation under the associated off-nominal conditions. The transition of these technologies into the commercial fleet will require their extensive validation and verification (V and V) and ultimate certification. The V and V of complex integrated systems poses major nontrivial technical challenges particularly for safety-critical operation under highly off-nominal conditions associated with aircraft loss-of-control events. This paper summarizes the V and V problem and presents a proposed process that could be applied to complex integrated safety-critical systems developed for preventing aircraft loss-of-control accidents. A summary of recent research accomplishments in this effort is also provided.

Belcastro, Christine M.↗
NASA NTRS2004

Multipurpose Crew Restraints for Long Duration Space Flights

With permanent human presence onboard the International Space Station (ISS), a crew will be living and working in microgravity, interfacing with their physical environment. Without optimum restraints and mobility aids (R&MA' s), the crewmembers may be handicapped for perfonning some of the on-orbit tasks. In addition to weightlessness, the confined nature of a spacecraft environment results in ergonomic challenges such as limited visibility and access to the activity area and may cause prolonged periods of unnatural postures. Thus, determining the right set of human factors requirements and providing an ergonomically designed environment are crucial to astronauts' well-being and productivity. The purpose of this project is to develop requirements and guidelines, and conceptual designs, for an ergonomically designed multi-purpose crew restraint. In order to achieve this goal, the project would involve development of functional and human factors requirements, design concept prototype development, analytical and computer modeling evaluations of concepts, two sets of micro gravity evaluations and preparation of an implementation plan. It is anticipated that developing functional and design requirements for a multi-purpose restraint would facilitate development of ergonomically designed restraints to accommodate the off-nominal but repetitive tasks, and minimize the performance degradation due to lack of optimum setup for onboard task performance. In addition, development of an ergonomically designed restraint concept prototype would allow verification and validation of the requirements defined. To date, we have identified "unique" tasks and areas of need, determine characteristics of "ideal" restraints, and solicit ideas for restraint and mobility aid concepts. Focus group meetings with representatives from training, safety, crew, human factors, engineering, payload developers, and analog environment representatives were key to assist in the development of a restraint concept based on previous flight experiences, the needs of future tasks, and crewmembers' preferences. Also, a catalog with existing IVA/EVA restraint and mobility aids has been developed. Other efforts included the ISS crew debrief data on restraints, compilation of data from MIR, Skylab and ISS on restraints, and investigating possibility of an in-flight evaluation of current restraint systems. Preliminary restraint concepts were developed and presented to long duration crewmembers and focus groups for feedback. Currently, a selection criterion is being refined for prioritizing the candidate concepts. Next steps include analytical and computer modeling evaluations of the selected candidate concepts, prototype development, and microgravity evaluations.

Whitmore, Mihriban↗