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 199 records · Page 11

Enabling Marine Energy Integration for Ocean Observing: Functional Requirements

Marine renewable energy (i.e., wave, tidal or ocean current, thermal gradient, and salinity gradient) or MRE can revolutionize ocean observing capabilities. Five use cases representing a range of ocean observing platforms were developed based on end-user feedback. Drawing from these use cases, common needs or functional requirements were developed to help guide the integration of MRE power delivery for ocean observation structures and functions. The functional requirements were determined from descriptions of the use cases, specifications of hardware that are used or closely associated with existing ocean observation platforms, and direct feedback from ocean observation sensor/platform developers and users. Twenty types of functional requirements were identified, including those associated with power and energy use; physical system requirements; temperature and depth; electrical, acoustic, and motion interference; and reliability. Each set of functional requirements is illustrated as features of the use cases. By defining functional requirements for MRE technology integration in ocean observing platforms, and focusing on end-user requirements, barriers to developing MRE-driven ocean observation missions can be reduced.

50 EE - Wind and Water Power Program - Water (EE-4↗

Capturing and Analyzing Requirements with FRET

FRET is an open source tool, developed at NASA Ames, for writing, understanding, formalizing, and analyzing requirements. In practice, requirements are typically written in natural language, which is ambiguous and consequently not amenable to formal analysis. Since formal, mathematical notations are unintuitive, requirements in FRET are entered in a restricted, natural language, called FRETish with precise unambiguous meaning. FRET helps users write FRETish requirements both by providing grammar information and examples during editing, but also through English and diagrammatic explanations to clarify subtle semantic issues. For each requirement, FRET automatically produces formalizations and supports interactive simulation of produced formalizations to ensure that they capture user intentions. Through its analysis portal, FRET connects to analysis tools by exporting verification code. Currently FRET connects to (1) the CoCoSim automated analysis tool for the verification of Simulink and Stateflow models, and (2) the Copilot runtime monitoring tool for the analysis of C programs. FRET also supports the consistency/realizability analysis of requirements for identifying conflicting requirements. In this tutorial, we introduce FRET and learn to speak and analyze FRETish through several examples.

FRET↗

Hydropower flexibility valuation tool for flow requirement evaluation

Timing of generation is becoming more and more valuable. This creates greater potential tension between environmental and power system objectives since both systems require their own flow patterns. Identifying win–win outcomes in this context requires being able to discuss the value of flexibility across stakeholder groups. This research proposes a two-stage optimization method to understand hydropower flexibility to meet both environmental and power system requirements. The tool simulates the two-settlement market process in the U.S. by maximizing revenues from both the day-ahead and real-time markets, subject to plant operational limits, regulatory flow and ramping requirements, and uncertainties associated with water availability and market prices. The model is formulated as linear programming problems and solved using IBM ILOG CPLEX optimizer. By examining a range of flow requirements, ramping constraints, and storage capacities, the proposed tool shows how to make more informed decisions to weigh the cost of specific flow requirements in the context of the overall license requirements. Results from the case study show that revenue is more sensitive to the ramping constraints than the minimum flow constraints. We also demonstrate that removing flow constraints in a dry month increases monthly revenue by up to 118%, as opposed to only 1% in a wet month. In addition, our results suggest that using a learning-based water flow forecast results in an increase of monthly revenue up to 6.4% compared with persistence forecast.

13 HYDRO ENERGY↗

Requirements on the gain calibration for LiteBIRD polarisation data with blind component separation

The detection of primordial B modes of the cosmic microwave background (CMB) could provide information about the early stages of the Universe's evolution. The faintness of this signal requires exquisite calibration accuracy and control of instrumental systematic effects which otherwise could bias the measurements. In this work, we study the impact of an imperfect relative polarisation gain calibration on the recovered value of the tensor-to-scalar ratio r for the LiteBIRD experiment, through the application of the blind Needlet Internal Linear Combination (NILC) foreground-cleaning method. We derive requirements on the relative calibration accuracy of the overall polarisation gain (Δg ν ) for each LiteBIRD frequency channel. Our results show that minimum variance techniques, as NILC, are less sensitive to systematic gain calibration uncertainties compared to a parametric approach, if the latter is not equipped with a proper modelling of these instrumental effects. In this study, the most stringent requirements are found in the channels where the CMB signal is relatively brighter, with the tightest constraints at 166 GHz (Δg ν ≈ 0.16%). This differs from the outcome of an analogous analysis performed with a parametric method, where the tightest requirements are obtained for the foreground-dominated channels. Gain calibration uncertainties, corresponding to the derived requirements, are then simultaneously propagated into all frequency channels. By doing so, we find that the overall impact on estimated r is lower than the total gain systematic budget for LiteBIRD approximately by a factor 5, due to the correlations of the impacts of gain calibration uncertainties in different frequency channels. In order to decouple the systematic effect from the specific choice of the model, we derive the requirements assuming constant spectral parameters for the foreground emission. To assess the robustness of the obtained results against more realistic scenarios, we repeat the analysis assuming sky models of intermediate and high complexity. In these further cases, we adopt an optimised NILC pipeline, called the Multi-Clustering NILC (MC-NILC). We find that the impact of gain calibration uncertainties on r is lower than the LiteBIRD gain systematics budget for the intermediate-complexity sky model. For the high-complexity case, instead, it would be necessary to tighten the requirements by a factor 1.8.

79 ASTRONOMY AND ASTROPHYSICS↗

Requirements and Conceptual Design of Off-gas Systems for the Reprocessing of Metallic Fuels

An assessment has been conducted to determine how key regulations regarding volatile radionuclide emissions to the atmosphere may apply to the off-gas streams associated with electrochemical reprocessing. The scope of this assessment was based upon a generic electrochemical reprocessing scheme with a throughput rate of 200 MTIHM/y applied to metallic fuel discharged from a sodium fast reactor (SFR), but the findings are able to be translated to other advanced nuclear scenarios as merited. Air dispersion modeling was performed using the EPA CAP-88 model and evaluated the uncontrolled decontamination factors (DFs) that would be required to achieve regulatory compliance with the dose-based limits set forth by EPA regulation 40 CFR 190.10(a). These DFs were compared to those required by fuel cycle–based limits set forth by EPA regulation 40 CFR 190.10(b). Two theoretical sites with disparate climatological conditions were selected for air dispersion modeling (Idaho and Tennessee). The radionuclides modeled included 3 H, 85 Kr, 129 I, and selected alpha-emitting transuranic isotopes (referred to here as 239 Pu-TRU <1y ). It was found that the fuel cycle-based limits in 40 CFR 190.10(b) are most restrictive for 85 Kr and 239 Pu-TRU <1y , with DFs of 3 and 6.1E+09, respectively. The dose-based limit as derived from 40 CFR 190.10(a) could require mitigation of tritium in some scenarios, with an estimated DF of about 3 for the reference scenarios. The fuel cycle-based limit for 129 I resulted in a DF of about 240 for the reference scenario. The need for iodine mitigation based on dose to the public depended upon the physical form of iodine as either particulate or vapor-phase species. Emission of iodine from the facility as a vapor necessitated DFs of about 2 but emission as a particulate would require DFs >6,000 to meet thyroid dose-based limits. Effects of physical form on needed iodine mitigation are significant, but the understanding of speciation of iodine both during electrochemical reprocessing and after release to the atmosphere is limited. The electrochemical processing unit operations were evaluated to identify potential release points for the volatile radionuclides and to assess the potential for retention of the radionuclides within the process (thus decreasing the need for mitigation). Mitigation strategies for 3 H, 85 Kr, 129 I, and 239 Pu-TRU <1y were identified. In all cases, there are reasonably achievable pathways to regulatory compliance, although in some cases additional R&D is merited to verify the chemical speciation of these isotopes and to develop and demonstrate potential treatment technologies for this application. Whether or not additional off-gas controls (beyond common operations such as HEPA filtration and oxygen and moisture control) are needed for any of these regulated or volatile radionuclides depends on the (a) type of facility (NRC-regulated or DOE), (b) used fuel process rate, (c) used fuel burnup and composition, (d) speciation and retention of volatile radionuclides in the process and in the cell gas cleanup system, (e) site-specific parameters such as location, meteorology, stack height, and site boundaries, and (f) levels of conservatism and safety factors used in assessing compliance to air emissions regulations. Performance of this assessment revealed several areas where information is lacking or additional research is required in order to better determine if or what kinds of off-gas control might be needed. First, and most significantly, the understanding of the chemical speciation and physical form and partitioning of iodine during electrochemical processing operations is lacking and prevents the ability to accurately assess the potential iodine mitigation requirements. Future research in this area should be multifaceted and include thermodynamic modeling of iodine speciation in different process steps, experiments to quantify the kinetics of vapor-phase and melt-phase transitions, bench-scale experiments to determine the potential chemical and physical form of iodine emissions from the electrorefining process, and verification of iodine behavior with experiments utilizing operational facilities. Similarly, an improved understanding of iodine behavior in the environment after release from the facility stack will be required to refine dose estimations, as particulate and vapor-phase emissions result in significantly different doses to the MEI.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

An Overview of Issues Related to IEEE Std 1547-2018 Requirements Regarding Voltage and Reactive Power Control

The revised Institute of Electrical and Electronics Engineers (IEEE) 1547 Standard for Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces (IEEE Std 1547-2018) was published in April 2018. This standard is one of the foundational documents in the United States needed for integrating distributed energy resources (DERs), including solar energy systems, with the electric distribution grid. The revised standard contains 11 chapters (clauses) and 8 annexes that comprise 136 pages. The revision is significantly different from the 2003 version, and it contains new concepts and new technical requirements. Each clause specifies information or requirements that apply to certain aspects important to the interconnection of DERs to the electric power system. Implementing the requirements necessitates a careful study of the underlying technical concept and requires the appropriate information required to calculate relevant settings and configurations. Various stakeholders have different roles in implementing the standard, and portions of the standard are directed toward a specific audience who must possess specialized information and technical training to use and apply the requirements. This document aims to (1) summarize a specific portion of the standard as concisely as possible and (2) provide the reader with introductory knowledge and information to support the utilization of the requirements.

14 SOLAR ENERGY↗

Community Requirements Meta-Analysis: Characterizing Needs and Opportunities for HPDF

This High Performance Data Facility (HPDF) Project is creating a new scientific user facility to provide advanced infrastructure for data-intensive science, supporting the DOE’s Office of Science (SC) community. HPDF’s mission is to enable and accelerate scientific discovery by delivering state-of-the-art data management infrastructure, capabilities, and tools. This meta-analysis examines the needs of the breadth of the SC community, captured in publicly available community reports or mission documents. The meta-analysis identifies and provides initial characterization of fifteen core requirements for the HPDF Project team to consider during the conceptual design phase. The fifteen requirements illustrate how scientific work among SC communities requires modern, seamless user experiences across the ASCR Ecosystem to advance the use of large volumes of heterogeneous data. The scientific community requires support for the missing middle of compute between local and HPC to interactively and collaboratively use growing datasets. Data producers and end users will benefit from enhanced data catalogs and portals that improve data access through advanced search of well curated data. The fifteen requirements are examined here organized across five themes for discussion. Examples in each theme illustrate the array of scientific needs that convey the important role that the fully realized and operational High Performance Data Facility will be able to play as an integral part of the evolving ASCR Ecosystem. Our amalgamated data tables from ESnet reports demonstrate ranges to the volumes of data HPDF must be concerned with, but limitations are inherent to this meta-analysis (see Key Challenges & Limitations). Feedback and validation of these requirements along with additional details and emergent community requirements will be gathered through user research and design activities.

97 MATHEMATICS AND COMPUTING↗

Future payload technology requirements

This paper presents the background and results of a study of future payload technology requirements. The overall objectives of the study were the identification and description of technology items that must be advanced beyond the current state of the art in order for early shuttle-era NASA payloads to meet their currently defined objectives. The purpose was to provide data that will effectively assist the NASA payload technology planning effort. A total of 91 payload technology requirements have been defined in detail with requirements occurring in all disciplines. Included in the description of these technology requirements are the current state-of-the-art, the level of technology advancement required, and the date when the technology will be needed. The highlights of the study are: (1) NASA must provide the major impetus to attain these technology requirements, (2) most of these technologies must be available in 3-4 years, and (3) about half of the technology advancements require a test in space.

Ikerd, H. M.↗

Generic waste management requirements for a controlled ecological life support system /CELSS/

Regenerative life support systems for future space missions will require closure of the waste-food loop. Each mission application will generate specific requirements for the waste management system. However, there are generic input and output requirements that can be identified when a probable scenario is chosen. This paper discusses the generic requirements when higher plants are chosen as the primary food source. Attention is focused on the quality and quantity of nutrients necessary for culturing higher plants. The types of wastes to be processed are also discussed. In addition, requirements generated by growing plants on three different substrates are presented. This work suggests that the mineral composition of waste materials may require minimal adjustment to satisfy the plant requirements.

Hoshizaki, T.↗

Science requirements for a global change technology architecture trade study

Science requirements for a global change technology initiative (GCTI) Architecture Trade Study were established by reviewing and synthesizing results from recent studies. A scientific rationale was adopted and used to identify a comprehensive set of measureables and their priorities. Spatial and temporal requirements for a number of measurement parameters were evaluated based on results from several working group studies. Science requirements were defined using these study results in conjunction with the guidelines for investigating global changes over a time scale of decades to centuries. Requirements are given separately for global studies and regional process studies. For global studies, temporal requirements are for sampling every 1 to 12 hours for atmospheric and radiation parameters and 1 day or more for most earth surface measurements. Therefore, the atmospheric measureables provide the most critical drivers for temporal sampling. Spatial sampling requirements vary from 1 km for land and ocean surface characteristics to 50 km for some atmospheric parameters. Thus, the land and ocean surface parameters have the more significant spatial variations and provide the most challenging spatial sampling requirements.

Suttles, John T.↗

Science requirements for a global change technology initiative architecture trade study

Science requirements for a Global Change Technology Initiative (GCTI) Architecture Trade Study were established by reviewing and synthesizing results from recent studies. A scientific rationale was adopted and used to identify a comprehensive set of measurables and their priorities. Spatial and temporal requirements for a number of measurement parameters were evaluated based on results from several working group studies. Science requirements were defined using these study results in conjunction with guidelines for investigating global changes over a time scale of decades to centuries. Requirements are given separately for global studies and regional process studies. For global studies, temporal requirements are for sampling every 1 to 12 hours for atmospheric and radiation parameters and 1 day or more for most Earth surface measurements. Therefore, the atmospheric measurables provide the most critical drivers for temporal sampling. Spatial sampling requirements vary from 1 km for land and ocean surface characteristics to 50 km for some atmospheric parameters. Thus, the land and ocean surface parameters have the more significant spatial variations and provide the most challenging spatial sampling requirements.

Suttles, John T.↗

Knowledge-based requirements analysis for automating software development

We present a new software development paradigm that automates the derivation of implementations from requirements. In this paradigm, informally-stated requirements are expressed in a domain-specific requirements specification language. This language is machine-understable and requirements expressed in it are captured in a knowledge base. Once the requirements are captured, more detailed specifications and eventually implementations are derived by the system using transformational synthesis. A key characteristic of the process is that the required human intervention is in the form of providing problem- and domain-specific engineering knowledge, not in writing detailed implementations. We describe a prototype system that applies the paradigm in the realm of communication engineering: the prototype automatically generates implementations of buffers following analysis of the requirements on each buffer.

Markosian, Lawrence Z.↗

HSCT high lift system aerodynamic requirements

The viewgraphs and discussion of high lift system aerodynamic requirements are provided. Low speed aerodynamics has been identified as critical to the successful development of a High Speed Civil Transport (HSCT). The airplane must takeoff and land at a sufficient number of existing or projected airports to be economically viable. At the same time, community noise must be acceptable. Improvements in cruise drag, engine fuel consumption, and structural weight tend to decrease the wing size and thrust required of engines. Decreasing wing size increases the requirements for effective and efficient low speed characteristics. Current design concepts have already been compromised away from better cruise wings for low speed performance. Flap systems have been added to achieve better lift-to-drag ratios for climb and approach and for lower pitch attitudes for liftoff and touchdown. Research to achieve improvements in low speed aerodynamics needs to be focused on areas most likely to have the largest effect on the wing and engine sizing process. It would be desirable to provide enough lift to avoid sizing the airplane for field performance and to still meet the noise requirements. The airworthiness standards developed in 1971 will be the basis for performance requirements for an airplane that will not be critical to the airplane wing and engine size. The lift and drag levels that were required to meet the performance requirements of tentative airworthiness standards established in 1971 and that were important to community noise are identified. Research to improve the low speed aerodynamic characteristics of the HSCT needs to be focused in the areas of performance deficiency and where noise can be reduced. Otherwise, the wing planform, engine cycle, or other parameters for a superior cruising airplane would have to be changed.

Paulson, John A.↗

A Methodology for Writing High Quality Requirement Specifications and for Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems-engineers are unable to build what analysts can not define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗

A Methodology for Writing High Quality Requirements Specification and Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems; engineers are unable to build what analysts can't define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗

Requirements, Verification, and Compliance (RVC) Database Tool

This paper describes the development, design, and implementation of the Requirements, Verification, and Compliance (RVC) database used on the International Space Welding Experiment (ISWE) project managed at Marshall Space Flight Center. The RVC is a systems engineer's tool for automating and managing the following information: requirements; requirements traceability; verification requirements; verification planning; verification success criteria; and compliance status. This information normally contained within documents (e.g. specifications, plans) is contained in an electronic database that allows the project team members to access, query, and status the requirements, verification, and compliance information from their individual desktop computers. Using commercial-off-the-shelf (COTS) database software that contains networking capabilities, the RVC was developed not only with cost savings in mind but primarily for the purpose of providing a more efficient and effective automated method of maintaining and distributing the systems engineering information. In addition, the RVC approach provides the systems engineer the capability to develop and tailor various reports containing the requirements, verification, and compliance information that meets the needs of the project team members. The automated approach of the RVC for capturing and distributing the information improves the productivity of the systems engineer by allowing that person to concentrate more on the job of developing good requirements and verification programs and not on the effort of being a "document developer".

Rainwater, Neil E., II↗

Energy Requirements of Hydrogen-utilizing Microbes: A Boundary Condition for Subsurface Life

Microbial ecosystems based on the energy supplied by water-rock chemistry carry particular significance in the context of geo- and astrobiology. With no direct dependence on solar energy, lithotrophic microbes could conceivably penetrate a planetary crust to a depth limited only by temperature or pressure constraints (several kilometers or more). The deep lithospheric habitat is thereby potentially much greater in volume than its surface counterpart, and in addition offers a stable refuge against inhospitable surface conditions related to climatic or atmospheric evolution (e.g., Mars) or even high-energy impacts (e.g., early in Earth's history). The possibilities for a deep microbial biosphere are, however, greatly constrained by life s need to obtain energy at a certain minimum rate (the maintenance energy requirement) and of a certain minimum magnitude (the energy quantum requirement). The mere existence of these requirements implies that a significant fraction of the chemical free energy available in the subsurface environment cannot be exploited by life. Similar limits may also apply to the usefulness of light energy at very low intensities or long wavelengths. Quantification of these minimum energy requirements in terrestrial microbial ecosystems will help to establish a criterion of energetic habitability that can significantly constrain the prospects for life in Earth's subsurface, or on other bodies in the solar system. Our early work has focused on quantifying the biological energy quantum requirement for methanogenic archaea, as representatives of a plausible subsurface metabolism, in anoxic sediments (where energy availability is among the most limiting factors in microbial population growth). In both field and laboratory experiments utilizing these sediments, methanogens retain a remarkably consistent free energy intake, in the face of fluctuating environmental conditions that affect energy availability. The energy yields apparently required by methanogens in these sediment systems for sustained metabolism are about half that previously thought necessary. Lowered energy requirements would imply that a correspondingly greater proportion of the planetary subsurface could represent viable habitat for microorganisms.

Hoehler, Tori M.↗

A Tool for Requirements-Based Programming

Absent a general method for mathematically sound, automated transformation of customer requirements into a formal model of the desired system, developers must resort to either manual application of formal methods or to system testing (either manual or automated). While formal methods have afforded numerous successes, they present serious issues, e.g., costs to gear up to apply them (time, expensive staff), and scalability and reproducibility when standards in the field are not settled. The testing path cannot be walked to the ultimate goal, because exhaustive testing is infeasible for all but trivial systems. So system verification remains problematic. System or requirements validation is similarly problematic. The alternatives available today depend on either having a formal model or pursuing enough testing to enable the customer to be certain that system behavior meets requirements. The testing alternative for non-trivial systems always have some system behaviors unconfirmed and therefore is not the answer. To ensure that a formal model is equivalent to the customer s requirements necessitates that the customer somehow fully understands the formal model, which is not realistic. The predominant view that provably correct system development depends on having a formal model of the system leads to a desire for a mathematically sound method to automate the transformation of customer requirements into a formal model. Such a method, an augmentation of requirements-based programming, will be briefly described in this paper, and a prototype tool to support it will be described. The method and tool enable both requirements validation and system verification for the class of systems whose behavior can be described as scenarios. An application of the tool to a prototype automated ground control system for NASA mission is presented.

Rash, James L.↗