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 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
DOE OSTI2016

Development of safety requirements for HTGRs design - 18467

The safety requirements for the design of High Temperature Gas-cooled Reactors (HTGRs), which is analogous to the IAEA specific safety requirements (SSR) for Light Water Reactor (LWR) design (IAEA SSR-2/1), has been developed by the research committee established in the Atomic Energy Society of Japan so as to incorporate the HTGR safety features demonstrated by High Temperature Engineering Test Reactor (HTTR), lessons learned from the accident of Fukushima Daiichi Nuclear Power Station and requirements for the coupling of the hydrogen production plants with nuclear plant. The safety design approach was determined to establish a high level of safety design standards by utilizing inherent safety features of HTGRs. The safety requirements is then developed using the objectives provisions tree methodology based on the safety design approach. The requirements for a structural integrity of fuel during accident conditions, for a confinement structure instead of a leak-tight pressure resistance containment vessel, for a passive residual heat removal from outside of reactor pressure vessel, etc., which are significantly different from those of LWR, are stated in the developed safety requirements. This paper describes overview of the proposed HTGR specific safety requirements. (authors)

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
NASA NTRSDate not supplied

Simplifying Requirements Formalization for Resource-Constrained Mission-Critical Software

Developing critical software requires adherence to rigorous software development practices, such as formal requirement specification and verification. Despite their importance, such practices are often considered as complex and challenging tasks that require a strong formal methods background. In this paper, we present our work on simplifying the formal requirements specification experience for resource-constrained mission critical software through the use of structured natural language. To this end, we connect NASA’s FRET, a formal requirement elicitation and authoring tool with the Shelley model checking framework for MicroPython code. We report our experience on using these tools to specify requirements and analyze code from the NASA Ames PHALANX exploration concept.

PHALANX exploration concept↗
DOE OSTI2021

Background Information on the Power Quality Requirements in IEEE Std 1547-2018

The revised Institute of Electrical and Electronics Engineers (IEEE) 1547-2018, Standard for Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces, 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, and energy storage 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 that are important to the interconnection of DERs to the electric power system. Implementing the requirements necessitates a careful study of the underlying technical concepts and requires appropriate information to calculate relevant settings and configurations. This document provides informative material on the requirements related to electrical power quality in IEEE Std 1547-2018, with the intent to equip the reader with basic knowledge and background information to improve understanding and use of the requirements specified.

14 SOLAR ENERGY↗
DOE OSTI2026

Cyber-Informed Engineering Requirements Framework Use Cases

The requirement analysis use case effort leverages the Cyber-Informed Engineering (CIE) requirements framework to examine two real-world scenarios: Battery Energy Storage System (BESS) installation at the Flatirons Campus, NLR; SCADA improvement program. This work evaluates the existing requirements for each use case, applies the CIE requirements framework, and assesses the benefits and enhancements gained compared to the current requirements. The results will advance CIE from concept to practical application by identifying key opportunities for integrating CIE principles into established engineering workflows during the requirements phase.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2004

Requirements based system risk modeling

The problem that we address in this paper is assessing the expected degree of success of the system or mission based on the degree to which each requirement is satisfied and the relative weight of the requirements. We assume a complete list of the requirements, the relevant risk elements and their probability of occurrence and the quantified effect of the risk elements on the requirements. In order to assess the degree to which each requirement is satisfied, we need to determine the effect of the various risk elements on the requirement.

risk↗
NASA NTRS2013

Center-TRACON Automation System (CTAS) En Route Trajectory Predictor Requirements and Capabilities

This requirements framework document is designed to support the capture of requirements and capabilities for state-of-the-art trajectory predictors (TPs). This framework has been developed to assist TP experts in capturing a clear, consistent, and cross-comparable set of requirements and capabilities. The goal is to capture capabilities (types of trajectories that can be built), functional requirements (including inputs and outputs), non-functional requirements (including prediction accuracy and computational performance), approaches for constraint relaxation, and input uncertainties. The sections of this framework are based on the Common Trajectory Predictor structure developed by the FAA/Eurocontrol Cooperative R&D Action Plan 16 Committee on Common Trajectory Prediction. It is assumed that the reader is familiar with the Common TP Structure.1 This initial draft is intended as a first cut capture of the En Route TS Capabilities and Requirements. As such, it contains many annotations indicating possible logic errors in the CTAS code or in the description provided. It is intended to work out the details of the annotations with NASA and to update this document at a later time.

framework↗
NASA NTRS2014

Satellite Ocean Color Sensor Design Concepts and Performance Requirements

In late 1978, the National Aeronautics and Space Administration (NASA) launched the Nimbus-7 satellite with the Coastal Zone Color Scanner (CZCS) and several other sensors, all of which provided major advances in Earth remote sensing. The inspiration for the CZCS is usually attributed to an article in Science by Clarke et al. who demonstrated that large changes in open ocean spectral reflectance are correlated to chlorophyll-a concentrations. Chlorophyll-a is the primary photosynthetic pigment in green plants (marine and terrestrial) and is used in estimating primary production, i.e., the amount of carbon fixed into organic matter during photosynthesis. Thus, accurate estimates of global and regional primary production are key to studies of the earth's carbon cycle. Because the investigators used an airborne radiometer, they were able to demonstrate the increased radiance contribution of the atmosphere with altitude that would be a major issue for spaceborne measurements. Since 1978, there has been much progress in satellite ocean color remote sensing such that the technique is well established and is used for climate change science and routine operational environmental monitoring. Also, the science objectives and accompanying methodologies have expanded and evolved through a succession of global missions, e.g., the Ocean Color and Temperature Sensor (OCTS), the Seaviewing Wide Field-of-view Sensor (SeaWiFS), the Moderate Resolution Imaging Spectroradiometer (MODIS), the Medium Resolution Imaging Spectrometer (MERIS), and the Global Imager (GLI). With each advance in science objectives, new and more stringent requirements for sensor capabilities (e.g., spectral coverage) and performance (e.g., signal-to-noise ratio, SNR) are established. The CZCS had four bands for chlorophyll and aerosol corrections. The Ocean Color Imager (OCI) recommended for the NASA Pre-Aerosol, Cloud, and Ocean Ecosystems (PACE) mission includes 5 nanometers hyperspectral coverage from 350 to 800 nanometers with three additional discrete near infrared (NIR) and shortwave infrared (SWIR) ocean aerosol correction bands. Also, to avoid drift in sensor sensitivity from being interpreted as environmental change, climate change research requires rigorous monitoring of sensor stability. For SeaWiFS, monthly lunar imaging accurately tracked stability at an accuracy of approximately 0.1% that allowed the data to be used for climate studies [2]. It is now acknowledged by the international community that future missions and sensor designs need to accommodate lunar calibrations. An overview of ocean color remote sensing and a review of the progress made in ocean color remote sensing and the variety of research applications derived from global satellite ocean color data are provided. The purpose of this chapter is to discuss the design options for ocean color satellite radiometers, performance and testing criteria, and sensor components (optics, detectors, electronics, etc.) that must be integrated into an instrument concept. These ultimately dictate the quality and quantity of data that can be delivered as a trade against mission cost. Historically, science and sensor technology have advanced in a "leap-frog" manner in that sensor design requirements for a mission are defined many years before a sensor is launched and by the end of the mission, perhaps 15-20 years later, science applications and requirements are well beyond the capabilities of the sensor. Section 3 provides a summary of historical mission science objectives and sensor requirements. This progression is expected to continue in the future as long as sensor costs can be constrained to affordable levels and still allow the incorporation of new technologies without incurring unacceptable risk to mission success. The IOCCG Report Number 13 discusses future ocean biology mission Level-1 requirements in depth.

Ocean Color↗
NASA NTRS2016

Applying Required Navigation Performance Concept for Traffic Management of Small Unmanned Aircraft Systems

In anticipation of a rapid increase in the number of civil Unmanned Aircraft System(UAS) operations, NASA is researching prototype technologies for a UAS Traffic Management (UTM) system that will investigate airspace integration requirements for enabling safe, efficient low-altitude operations. One aspect a UTM system must consider is the correlation between UAS operations (such as vehicles, operation areas and durations), UAS performance requirements, and the risk to people and property in the operational area. This paper investigates the potential application of the International Civil Aviation Organizations (ICAO) Required Navigation Performance (RNP) concept to relate operational risk with trajectory conformance requirements. The approach is to first define a method to quantify operational risk and then define the RNP level requirement as a function of the operational risk. Greater operational risk corresponds to more accurate RNP level, or smaller tolerable Total System Error (TSE). Data from 19 small UAS flights are used to develop and validate a formula that defines this relationship. An approach to assessing UAS-RNP conformance capability using vehicle modeling and wind field simulation is developed to investigate how this formula may be applied in a future UTM system. The results indicate the modeled vehicles flight path is robust to the simulated wind variation, and it can meet RNP level requirements calculated by the formula. The results also indicate how vehicle-modeling fidelity may be improved to adequately verify assessed RNP level.

required navigation performance↗
NASA NTRS2016

Early Engagement of Safety and Mission Assurance Expertise Using Systems Engineering Tools: A Risk-Based Approach to Early Identification of Safety and Assurance Requirements

Decades of systems engineering practice have demonstrated that the earlier the identification of requirements occurs, the lower the chance that costly redesigns will needed later in the project life cycle. A better understanding of all requirements can also improve the likelihood of a design's success. Significant effort has been put into developing tools and practices that facilitate requirements determination, including those that are part of the model-based systems engineering (MBSE) paradigm. These efforts have yielded improvements in requirements definition, but have thus far focused on a design's performance needs. The identification of safety & mission assurance (S&MA) related requirements, in comparison, can occur after preliminary designs are already established, yielding forced redesigns. Engaging S&MA expertise at an earlier stage, facilitated by the use of MBSE tools, and focused on actual project risk, can yield the same type of design life cycle improvements that have been realized in technical and performance requirements.

Requirement↗
NASA NTRS2017

Cleared for Launch - Lessons Learned from the OSIRIS-REx System Requirements Verification Program

Requirements verification of a large flight system is a challenge. It is especially challenging for engineers taking on their first role in space systems engineering. This paper describes our approach to verification of the Origins, Spectral Interpretation, Resource Identification, Security-Regolith Explorer (OSIRIS-REx) system requirements. It also captures lessons learned along the way from developing systems engineers embroiled in this process. We begin with an overview of the mission and science objectives as well as the project requirements verification program strategy. A description of the requirements flow down is presented including our implementation for managing the thousands of program and element level requirements and associated verification data. We discuss both successes and methods to improve the managing of this data across multiple organizational interfaces. Our approach to verifying system requirements at multiple levels of assembly is presented using examples from our work at instrument, spacecraft, and ground segment levels. We include a discussion of system end-to-end testing limitations and their impacts to the verification program. Finally, we describe lessons learned that are applicable to all emerging space systems engineers using our unique perspectives across multiple organizations of a large NASA program.

Requirements Verification↗
NASA NTRS2019

Bridging the Gap Between Requirements and Model Analysis: Evaluation on Cyber-Physical Challenge Problems

We present a framework for introducing high-level requirement specifications in the automated analysis of dataflow models. By integrating the FRET requirements elicitation tool with the CoCoSim analyzer, our framework enables the analysis of hierarchical Simulink models against requirements written in a restricted English language. More precisely, we support: automatic extraction of Simulink model information and association of high-level requirements with target model signals and components; translation of temporal logic formulas into synchronous dataflow CoCoSpec specifications as well as Simulink monitors; and interpretation of counterexamples produced by the analysis both at the requirement and model level. The features provided by our framework are generic and can be used to integrate other requirements elicitation and Simulink/Lustre analysis tools. We report on the lessons learned from the application of our approach to the Lockheed Martin Cyber-Physical, aerospace-inspired challenge problems. For the analysis, we used the Kind2, Zustre, and Simulink Design Verifier (SLDV) tools.

Simulink↗
NASA NTRSDate not supplied

Monitoring ROS2: From Requirements to Autonomous Robots

Context/Goals - Capture mission requirements in high-level language. - Monitor requirements for robots. At a Glance - Transform requirements into runtime monitors for ROS2: - Requirements elicitation.* - Transform requirements into Temporal Logic formulas.* - Transform Temporal Logic formulas into runtime monitors.* - Generate hard real-time code for monitors.* - Generate ROS2 application directly from requirements.+ *Steps done in prior work. +Steps extended from prior work.

Runtime verification↗
NASA NTRSDate not supplied

Exploring Requirements for Software that Learns: A Research Preview

Context & motivation: The development of software that learns has revolutionized how many systems perform. For the most part, these systems are neither safety- nor mission-critical. However, as technology and aspirations advance, there is an increased desire and need for Machine Learning (ML) software in safety- and mission-critical systems, e.g., driverless cars or autonomous space robotics. Problem: In these domains, reliability is crucial and systems have to undergo much scrutiny in terms of both the developed artefacts and the adopted development process. Central to the development of such systems is the elicitation and definition of software requirements that are used to guide the design and verification process. The addition of software components that learn, and the associated capability for unforeseen behavior, makes defining detailed software requirements especially difficult. Principal ideas/results: In this paper, we identify unique characteristics of software requirements that are specific to ML components. To this end, we collect and examine requirements from both academic and industrial sources. Contribution: To the best of our knowledge, this is the first work that presents real-life, industrial patterns of requirements for ML components. Furthermore, this paper identifies key characteristics and provides a foundation for developing a taxonomy of requirements for software that learns.

Probabilistic requirements↗
DOE OSTI2014

Generalized Information Architecture for Managing Requirements in IBM's Rational DOORS® Application

When a requirements engineering effort fails to meet expectations, often times the requirements management tool is blamed. Working with numerous project teams at Sandia National Laboratories over the last fifteen years has shown us that the tool is rarely the culprit; usually it is the lack of a viable information architecture with well-designed processes to support requirements engineering. This document illustrates design concepts with rationale, as well as a proven information architecture to structure and manage information in support of requirements engineering activities for any size or type of project. This generalized information architecture is specific to IBM's Rational DOORS (Dynamic Object Oriented Requirements System) software application, which is the requirements management tool in Sandia's CEE (Common Engineering Environment). This generalized information architecture can be used as presented or as a foundation for designing a tailored information architecture for project-specific needs. It may also be tailored for another software tool.

Aragon, Kathryn Mary↗
DOE OSTI2017

Implementation of Energy Code Controls Requirements in New Commercial Buildings

Most state energy codes in the United States are based on one of two national model codes; ANSI/ASHRAE/IES 90.1 (Standard 90.1) or the International Code Council (ICC) International Energy Conservation Code (IECC). Since 2004, covering the last four cycles of Standard 90.1 updates, about 30% of all new requirements have been related to building controls. These requirements can be difficult to implement and verification is beyond the expertise of most building code officials, yet the assumption in studies that measure the savings from energy codes is that they are implemented and working correctly. The objective of the current research is to evaluate the degree to which high impact controls requirements included in commercial energy codes are properly designed, commissioned and implemented in new buildings. This study also evaluates the degree to which these control requirements are realizing their savings potential. This was done using a three-step process. The first step involved interviewing commissioning agents to get a better understanding of their activities as they relate to energy code required controls measures. The second involved field audits of a sample of commercial buildings to determine whether the code required control measures are being designed, commissioned and correctly implemented and functioning in new buildings. The third step includes compilation and analysis of the information gather during the first two steps. Information gathered during these activities could be valuable to code developers, energy planners, designers, building owners, and building officials.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2022

Design Requirements and Software Specification for the Autonomous Energy Management Software System for Small Commercial Buildings

Commercial buildings are responsible for approximately 20 percent of the total United States energy consumption and greenhouse gas emissions. Over 85 percent of these buildings lack building automation systems. Many of these buildings are small (<50,000 square feet), underserved, and use rooftop units for heating, ventilation, and air-conditioning needs. Because these buildings lack proper energy management systems, they have several operational deficiencies that lead to excess energy consumption. Studies have shown that managing the rooftop units heating and cooling set points, schedules, setbacks, and optimal start can result in 20 to 25 percent reduction in electricity consumption in small commercial buildings. In addition, improving demand flexibility of these buildings will result additional cost savings for the building owner. Therefore, the Department of Energy’s Building Technologies Office approved a project to address the needs for small commercial buildings. The project is led by Pacific Northwest National Laboratory (PNNL) with Intellimation LLC as the cooperative research and development agreement partner. The primary goal of the project is to develop and validate an autonomous energy management software (AEMS) system that will continuously optimize small commercial building operations by minimizing energy consumption and cost, while providing a solution for maximizing decarbonization benefits from electrification of buildings. The work will leverage the vast experience of PNNL research and development staff who have over two decades of experience in developing and successfully transferring software technologies to the private sector. This solution will be jointly developed with Intellimation, a company that plans to use it to scale their building energy efficiency (EE) and grid services offering. Widespread deployment of the AEMS system will improve the EE and demand flexibility of the building commercial building stock. It should also support cities and states in meeting their climate change mitigation goals. This document describes the various EE and grid service features of the AEMS system, infrastructure and data required to implement those features, and how the features should be automated. It also details how the various features will be tested and validated, including field validation. The document also details what flexibility the users have and how they will be able to leverage those capabilities exercise those. The intent is to create an AEMS system that would support scalable deployment, requires minimal configuration, and is easy to maintain over its expected lifespan. The initial alpha release of AEMS system is planned for March 2023, and the beta release is planned for the summer of 2023. The final release is planned for March 2024. Section 2 of the report documents the relevant building types that AEMS is suitable for. Section 3 documents EE features that will be supported. It will also include the data requirements, hardware requirements, implementation details, and how EE features will be tested and validated. Grid service features will be documented in section 4, including data requirements, hardware requirements, implementation details, and how the services will be tested and validated. Planned next steps are described in section 5.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2025

LAMP Project Facility and Space Requirements

The project will require significant space over the lifetime of the project to successfully execute design, technology maturation, component testing and verification, and final removal and installation. The types of space required falls into three general categories: office, storage, and laboratory. Figure 1 below summarizes the project space requirements by project lifecycle. The specific color coding indicates the availability (and potential risk to the project) of the particular type of space: green indicates space that is already allocated and in use by the LAMP project; yellow indicates space that is expected to be easily transitioned from its current use to the project; red indicates a space that is use by multiple users or other projects, and will most likely require high-level negotiations and planning to become available to the project. Figure 2 summarizes the LAMP Space Requirements by calendar year and type throughout the duration of the project. As can be seen in Fig. 2, the maximum space needed by the project exceeds 40,000 square feet, with an average space requirement over the lifetime of the project equal to approximately 25,000 square feet.

43 PARTICLE ACCELERATORS↗
NASA NTRS1973

Study of data collection platform concepts: Data collection system user requirements

The overall purpose of the survey was to provide real world data on user requirements. The intent was to assess data collection system user requirements by questioning actual potential users rather than speculating on requirements. The end results of the survey are baseline requirements models for both a data collection platform and a data collection system. These models were derived from the survey results. The real value of these models lies in the fact that they are based on actual user requirements as delineated in the survey questionnaires. Some users desire data collection platforms of small size and light weight. These sizes and weights are beyond the present state of the art. Also, the survey provided a wealth of information on the nature and constituency of the data collection user community as well as information on user applications for data collection systems. Finally, the data sheds light on the generalized platform concept. That is, the diversity of user requirements shown in the data indicates the difficulty that can be anticipated in attempting to implement such a concept.

Source record↗