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 307 records · Page 17

Connecting Requirements to Architecture and Analysis via Model-Based Systems Engineering

In traditional systems engineering practice, architecture, concept development, and requirements development are related but still separate activities. Concepts for operation, key technical approaches, and related proofs of concept are developed. These inform the formulation of an architecture at multiple levels, starting with the overall system composition and functionality and progressing into more detail. As this formulation is done, a parallel activity develops a set of English statements that constrain solutions. These requirements are often called "shall statements" since they are formulated to use "shall." The separation of requirements from design is exacerbated by well-meaning tools like the Dynamic Object-Oriented Requirements System (DOORS) that remained separated from engineering design tools. With the Europa Clipper project, efforts are being taken to change the requirements development approach from a separate activity to one intimately embedded in formulation effort. This paper presents a modeling approach and related tooling to generate English requirement statements from constraints embedded in architecture definition.

Cole, Bjorn F.↗

Requirements for an Integrated UAS CNS Architecture

The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) is investigating revolutionary and advanced universal, reliable, always available, cyber secure and affordable Communication, Navigation, Surveillance (CNS) options for all altitudes of UAS operations. In Spring 2015, NASA issued a Call for Proposals under NASA Research Announcements (NRA) NNH15ZEA001N, Amendment 7 Subtopic 2.4. Boeing was selected to conduct a study with the objective to determine the most promising candidate technologies for Unmanned Air Systems (UAS) air-to-air and air-to-ground data exchange and analyze their suitability in a post-NextGen NAS environment. The overall objectives are to develop UAS CNS requirements and then develop architectures that satisfy the requirements for UAS in both controlled and uncontrolled air space. This contract is funded under NASAs Aeronautics Research Mission Directorates (ARMD) Aviation Operations and Safety Program (AOSP) Safe Autonomous Systems Operations (SASO) project and proposes technologies for the Unmanned Air Systems Traffic Management (UTM) service. Communications, Navigation and Surveillance (CNS) requirements must be developed in order to establish a CNS architecture supporting Unmanned Air Systems integration in the National Air Space (UAS in the NAS). These requirements must address cybersecurity, future communications, satellite-based navigation APNT, and scalable surveillance and situational awareness. CNS integration, consolidation and miniaturization requirements are also important to support the explosive growth in small UAS deployment. Air Traffic Management (ATM) must also be accommodated to support critical Command and Control (C2) for Air Traffic Controllers (ATC). This document therefore presents UAS CNS requirements that will guide the architecture.

Templin, Fred↗

Quantification of Dynamic Model Validation Metrics Using Uncertainty Propagation from Requirements

The Space Launch System, NASA's new large launch vehicle for long range space exploration, is presently in the final design and construction phases, with the first launch scheduled for 2019. A dynamic model of the system has been created and is critical for calculation of interface loads and natural frequencies and mode shapes for guidance, navigation, and control (GNC). Because of the program and schedule constraints, a single modal test of the SLS will be performed while bolted down to the Mobile Launch Pad just before the first launch. A Monte Carlo and optimization scheme will be performed to create thousands of possible models based on given dispersions in model properties and to determine which model best fits the natural frequencies and mode shapes from modal test. However, the question still remains as to whether this model is acceptable for the loads and GNC requirements. An uncertainty propagation and quantification (UP and UQ) technique to develop a quantitative set of validation metrics that is based on the flight requirements has therefore been developed and is discussed in this paper. There has been considerable research on UQ and UP and validation in the literature, but very little on propagating the uncertainties from requirements, so most validation metrics are "rules-of-thumb;" this research seeks to come up with more reason-based metrics. One of the main assumptions used to achieve this task is that the uncertainty in the modeling of the fixed boundary condition is accurate, so therefore that same uncertainty can be used in propagating the fixed-test configuration to the free-free actual configuration. The second main technique applied here is the usage of the limit-state formulation to quantify the final probabilistic parameters and to compare them with the requirements. These techniques are explored with a simple lumped spring-mass system and a simplified SLS model. When completed, it is anticipated that this requirements-based validation metric will provide a quantified confidence and probability of success for the final SLS dynamics model, which will be critical for a successful launch program, and can be applied in the many other industries where an accurate dynamic model is required.

Brown, Andrew M.↗

Validation of Minimum Display Requirements for a UAS Detect and Avoid System

The full integration of Unmanned Aircraft Systems (UAS) into the National Airspace System (NAS), a prerequisite for enabling a broad range of public and commercial UAS operations, presents several technical challenges to UAS developers, operators and regulators. A primary barrier is the inability for UAS pilots (situated at a ground control station, or GCS) to comply with Title 14 Code of Federal Regulations sections 91.111 and 91.113, which require pilots to “see and avoid” other aircraft in order to maintain well clear. UAS pilots’ removal from the flight deck of the aircraft necessitates the development of a UAS-specific system for detecting nearby traffic and displaying traffic information to the pilot to support their ability to maintain an objectively defined “DAA well clear” threshold from other aircraft. This new UAS-specific function of remaining DAA well clear is called traffic avoidance. The resulting Detect and Avoid (DAA) system, however, will be subject to a collection of requirements that manufacturers will be obligated to meet in order to certify their equipment. RTCA Special Committee 228 (SC-228), a consortium of representatives from government, industry and academia, is responsible for developing and documenting the Minimum Operational Performance Standards (MOPS) for UAS DAA systems. The present study is the final in a series of human-in-the-loop (HITL) experiments designed to explore and test the various display and alerting requirements being incorporated into the DAA MOPS. Whereas the prior DAA HITLs examined a wide variety of DAA display features and concepts, the current experiment aims to validate the latest minimum display requirements for Phase 1 of the DAA MOPS. Rather than test different display concepts, this study tests two configurations of a MOPS-compatible DAA display: a version that is integrated into the primary navigation and control display of the GCS and a version that is physically separated from the primary display. This manipulation tests the draft minimum requirement that allows the DAA traffic display to be a separate, or standalone, configuration. This type of configuration is a more achievable near-term technology solution since it does not stipulate additional certification or integration requirements on UAS manufacturers. However, a standalone display configuration has the potential to result in pilot performance issues resulting from the cognitive costs of switching between the primary DAA display and the primary navigation and control display. This configuration is also particularly susceptible to errors if the displays are in different orientations (e.g., north-up versus track-up). Both the integrated and standalone display configurations were presented to 16 active UAS pilots in a medium-fidelity simulation, which included confederate air traffic controllers and pseudo pilots operating simulated manned traffic. Pilots were tasked with navigating two different mission routes while maintaining DAA well clear with scripted conflicts. Pilot response times (i.e., measured response) and ability to remain DAA well clear are reported. Primary results indicate that both display configurations resulted in favorable response times and well clear rates. While there were clear trends of pilots objectively performing better in the integrated display condition, with several measured response metrics reaching statistical significance, the differences between the two displays were typically moderate. While the primary variable of DAA display location did not have an especially large impact on pilot performance on its own, when examined alongside the type of DAA threat the pilot was facing (a caution-level versus a warning-level alert), the response time benefits associated with the integrated display were amplified. The implications of these American Institute of Aeronautics and Astronautics 2 results on the Phase 1 DAA MOPS and the connection of this data to previous studies is also discussed.

detect and avoid↗

Bridging the Gap Between Requirements and Simulink Model Analysis

Formal verification and simulation are powerful tools for the verification of requirements against complex systems. Requirements are developed in early stages of the software lifecycle and are typically expressed in natural language. There is a gap between such requirements and their software implementations.We present a framework that bridges this gap by supporting a tight integration and feedback loop between high-level requirements and their analysis against software artifacts. Our framework implements an analysis portal within the fret requirements elicitation tool, thus forming an end-to-end, open-source environment where requirements are written in an intuitive, structured natural language, and are verified automatically against Simulink models.

Mavridou, Anastasia↗

Bridging the Gap Between Requirements and Simulink Model Analysis

Formal veri fication and simulation are powerful tools for the veri fication of requirements against complex systems. Requirements are developed in early stages of the software lifecycle and are typically expressed in natural language. There is a gap between such requirements and their software implementations. We present a framework that bridges this gap by supporting a tight integration and feedback loop between high-level requirements and their analysis against software artifacts. Our framework implements an analysis portal within the fret requirements elicitation tool, thus forming an end-to-end, open-source environment where requirements are written in an intuitive, structured natural language, and are veri fied automatically against Simulink models.

FRET↗

Requirements Development and Management on the Psyche Project

In January 2017, Psyche was one of two mission concepts selected by NASA for flight as part of the 14th Discovery mission competition. The project has been staffing up and maturing the spacecraft, instrument and mission system baseline designs on the path towards a 2022 launch. During much of 2018, the Project has been executing the lifecycle stage called Phase B, “Preliminary Design and Technology Completion,” one key element of which is the development and management of requirements at various levels. In the case of the Psyche project, this process has been particularly unique for several reasons. The project utilizes a Solar Electric Propulsion (SEP) Chassis from Space Systems Loral (SSL), a high volume manufacturer of commercial geostationary (GEO) telecom spacecraft based on the 1300 satellite bus. While SSL has an extensive, well-vetted set of requirements based on their very successful Earth-orbiting product line, translating that heritage to a deep space science mission required special care. In addition to the differences associated with the deep space environment and longer communication times, new interfaces had to be incorporated. While a substantial portion of the Flight System consists of the SEP Chassis, there were several new interfaces within various subsystems between SSL components and those provided by JPL and other contractors. Managing these interfaces through requirements at a relatively higher level than normally seen on internal or external builds proved challenging. Finally, the Psyche spacecraft plans to host the flight terminal of the Deep Space Optical Communications (DSOC) technology demonstration, which is itself a separate project with its own requirements that must be flowed down and managed. This paper will present an overview of the requirement development and management process for the Psyche project. It will discuss in detail the various challenges summarized above, the methods and decisions chosen to address them, and evaluate their overall effectiveness at this stage in the project.

Elkins-Tanton, Linda T.↗

A Framework for Writing Science Measurement Requirements and its Application to the Europa Multiple Flyby Mission

Science-engineering communication is critical to the success of any science-driven mission. The process of building this understanding relies on a shared language for communicating science needs and engineering results, which can be particularly difficult on large space-science missions where many different institutions contribute to the science team. The Science Traceability Matrix can be used to formalize this communication pathway, but it has limited use in the development of the science requirements flow down, and vary in format, scope and content from mission to mission. There are many guidelines on developing well-constructed requirements in general, but very little is published on how to actually write these science-driven requirements in a systematic way. This paper discusses the measurement-domain science traceability and alignment framework, or M-STAF, which was developed to help frame the conversation between scientists and engineers in the development of science measurement requirements. The MSTAF provides a common language that can be used to ensure consistency across instruments, completeness in the coverage of the requirements, and traceability of the engineering work to the science objectives of the project. This work discusses the framework in the context of other communication tools, how it can be implemented on a flight project, and provides examples of how it might be used to improve the measurement requirements set for a project. The general framework is presented through the lens of its potential application on the planned Europa Mission.

Oaida, Bogdan V.↗

Implementation Requirements for Nasa Approved Workmanship Standards

This NASA technical standard provides uniform engineering and technical requirements for processes, procedures, practices, and methods that have been endorsed as standard for NASA facilities, programs, and projects, including requirements for selecting, applying, and designing hardware for manufacturability and reliability. This standard establishes NASA workmanship requirements, and clarifications, additions, and exceptions to requirements specified in NASA adopted industry consensus standards identified as required for use by NPR 8735.2, Hardware Quality Assurance Program Requirements for Programs and Projects

workmanship standards↗

Energy Cost Impact of Non-Residential Energy Code Requirements

The 2012 International Energy Conservation Code contains 396 separate requirements applicable to non-residential buildings; however, there is no systematic analysis of the energy cost impact of each requirement. Consequently, limited code department budgets for plan review, inspection, and training cannot be focused on the most impactful items. An inventory and ranking of code requirements based on their potential energy cost impact is under development. The initial phase focuses on office buildings with simple HVAC systems in climate zone 4C. Prototype building simulations were used to estimate the energy cost impact of varying levels of non-compliance. A preliminary estimate of the probability of occurrence of each level of non-compliance was combined with the estimated lost savings for each level to rank the requirements according to expected savings impact. The methodology to develop and refine further energy cost impacts, specific to building type, system type, and climate location is demonstrated. As results are developed, an innovative alternative method for compliance verification can focus efforts so only the most impactful requirements from an energy cost perspective are verified for every building and a subset of the less impactful requirements are verified on a random basis across a building population. The results can be further applied in prioritizing training material development and specific areas of building official training.

code compliance↗

Energy Cost Impact of Non-Residential Energy Code Requirements

The 2012 International Energy Conservation Code contains 396 separate requirements applicable to non-residential buildings; however, there is no systematic analysis of the energy cost impact of each requirement. Consequently, limited code department budgets for plan review, inspection, and training cannot be focused on the most impactful items. An inventory and ranking of code requirements based on their potential energy cost impact is under development. The initial phase focuses on office buildings with simple HVAC systems in climate zone 4C. Prototype building simulations were used to estimate the energy cost impact of varying levels of non-compliance. A preliminary estimate of the probability of occurrence of each level of non-compliance was combined with the estimated lost savings for each level to rank the requirements according to expected savings impact. The methodology to develop and refine further energy cost impacts, specific to building type, system type, and climate location is demonstrated. As results are developed, an innovative alternative method for compliance verification can focus efforts so only the most impactful requirements from an energy cost perspective are verified for every building and a subset of the less impactful requirements are verified on a random basis across a building population. The results can be further applied in prioritizing training material development and specific areas of building official training.

Energy Codes, code compliance↗

Developing Waste-Driven Design Requirements for Filtration and Ion-Exchange at the Hanford LAWPS Facility - 16394

The United States Department of Energy is building the Low Activity Waste Pretreatment System (LAWPS) at the Hanford site near Richland, Washington to treat liquid tank waste. The primary unit operations are filtration for solids removal and ion-exchange for cesium-137 removal. The properties of the stored waste are diverse, therefore the design requirements need to allow for a variety of feeds from the Hanford tank farms. However, it is not cost effective to allow a few rare feeds to define the requirements when there are other options for treating the rare wastes. The waste-derived design requirements were based on trends from this data. The primary feed requirements that will drive filtration and ion-exchange performance are solids content of the feed, cesium to sodium ratio, and potassium concentration. Additionally, aluminum and total organic carbon (TOC) concentrations are considered for flammable gas generation. For the cesium and potassium concentrations, the available experimental data was collected, sorted, and compared against the historic requirements. The design basis for cesium and potassium feed parameters developed here enveloped all but a couple outlier tanks. A review of available grab sample data indicates that occasionally the samples would have up to 0.8 wt% solids concentration. One single sample had 3.3 wt% solids concentration. These solids concentrations were assigned as the nominal and upper bounding solids concentrations. Flammable gas generation does not directly impact the ion exchange process throughput but does impact the design safety requirements, thus TOC and aluminum concentrations (which are inputs to the flammable gas calculations) were examined in a similar way, but were paired together through a simplified correlation to reach an upper bounding value of 0.6 wt% TOC*Al{sup 0.4}. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

Recommendations for Minimum Required Diagnostics Information

The rapid growth of electrified transportation, including light- and medium-duty electric vehicles (EVs) as a mobility solution requires a reliable EV-charging infrastructure. To advance charging reliability, the ChargeX Consortium reports “Recommendations for Minimum Required Error Codes for Electric Vehicle Charging Infrastructure” and “Implementation Guide for Minimum Required Error Codes in Electric Vehicle Charging Infrastructure” provided recommendations for a set of minimum required error codes (MRECs), their functional and responsibility classifications, and a guide for their implementation, using Open Charge Point Protocol (OCPP) versions 1.6J4 and 2.0.1.5 These reports outline a recommended practice for consistent error reporting and interpretation, which is essential for communicating issues uniformly across the complex and diverse EV-charging ecosystem. However, MRECs are just one part of diagnosing issues; another critical part is obtaining enough information about the current state and performance of the various charging components to identify root causes for each of the error codes. This additional diagnostics data can be used by technicians or automated systems to understand the context around an issue, allowing for timely resolution, decreased maintenance costs, and increased charging reliability. During everyday operations, data are regularly collected and analyzed across the ecosystem. Although sharing of all that available data would be great for diagnostics, concerns on data ownership, privacy, and original equipment manufacturer (OEM) intellectual property pose a challenge. To overcome this obstacle, this report proposes a set of minimum required diagnostic information (MRDI) and recommends that the industry implement these uniformly across the North American EV charging ecosystem. MRDI provides a means to exchange only data deemed necessary for root cause determination.

33 ADVANCED PROPULSION SYSTEMS↗

Recommendations for Minimum Required Diagnostics Information for Electric Vehicle Charging Infrastructure

The rapid growth of electrified transportation, including light- and medium-duty electric vehicles (EVs) as a mobility solution requires a reliable EV charging infrastructure. To advance charging reliability, the ChargeX Consortium reports “Recommendations for Minimum Required Error Codes for Electric Vehicle Charging Infrastructure” and “Implementation Guide for Minimum Required Error Codes in Electric Vehicle Charging Infrastructure” have provided recommendations for a set of minimum required error codes (MRECs), their functional and responsibility classifications, and a guide for their implementation using OCPP versions 1.6J and 2.0.1. These reports outline a recommended practice for consistent error reporting and interpretation, which is essential for communicating issues uniformly across the complex and diverse EV charging ecosystem. However, MRECs are just one part of diagnosing issues, another critical part is obtaining enough information about the current state and performance of the various charging components to identify root causes for each of the error codes. This additional diagnostics data can be used by technicians or automated systems to understand the context around an issue, allowing for timely resolution, decreased maintenance costs, and increased charging reliability. During everyday operations, data is regularly collected and analyzed across the ecosystem. Although sharing of all that available data would be great for diagnostics, concerns on data ownership, privacy, and OEM intellectual property pose a challenge. To overcome this obstacle, this report proposes a set of Minimum Required Diagnostic Information (MRDI) and recommends that the industry implement these uniformly across the North American EV charging ecosystem. MRDI provides a means to exchange only data deemed necessary for root cause determination.

32 - ENERGY CONSERVATION, CONSUMPTION, AND UTILIZA↗

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↗

Infusing Stretch Goal Requirements into the Constellation Program

In 2004, the Vision for Space Exploration (VSE) was announced by the United States President's Administration in an effort to explore space and to extend a human presence across our solar system. Subsequently, the National Aeronautics and Space Administration (NASA) established the Exploration Systems Mission Directorate (ESMD) to develop a constellation of new capabilities, supporting technologies, and foundational research that allows for the sustained and affordable exploration of space. Then, ESMD specified the primary mission for the Constellation Program to carry out a series of human expeditions, ranging from Low Earth Orbit (LEO) to the surface of Moon, Mars, and beyond for the purposes of conducting human exploration of space. Thus, the Constellation Program was established at the Lyndon B. Johnson Space Center (JSC) to manage the development of the flight and ground infrastructure and systems that can enable continued and extended human access to space. Constellation Program's "Design Objectives" call for an early attention to the program's life cycle costs management through the Program's Need, Goals, and Objectives (NGO) document, which provides the vision, scope, and key areas of focus for the Program. One general policy of the Constellation Program, found in the Constellation Architecture Requirements Document (CARD), states: "A sustainable program hinges on how effectively total life cycle costs are managed. Developmental costs are a key consideration, but total life cycle costs related to the production, processing, and operation of the entire architecture must be accounted for in design decisions sufficiently to ensure future resources are available for ever more ambitious missions into the solar system....It is the intent of the Constellation Program to aggressively manage this aspect of the program using the design policies and simplicity." To respond to the Program's strong desire to manage the program life cycle costs, special efforts were established to identify operability requirements to influence flight vehicle and ground infrastructure design in order to impact the life cycle operations costs, and stretch goal requirements were introduced to the Program. This paper will describe how these stretch goal requirements were identified, developed, refined, matured, approved, and infused into the CARD. The paper will also document several challenges encountered when infusing the stretch goal requirements into the Constellation Program.

Operability↗

Are We There Yet? Determining the Adequacy of Formalized Requirements and Test Suites

Structural coverage metrics have traditionally categorized code as either covered or uncovered. Recent work presents a stronger notion of coverage, checked coverage, which counts only statements whose execution contributes to an outcome checked by an oracle. While this notion of coverage addresses the adequacy of the oracle, for Model-Based Development of safety critical systems, it is still not enough; we are also interested in how much of the oracle is covered, and whether the values of program variables are masked when the oracle is evaluated. Such information can help system engineers identify missing requirements as well as missing test cases. In this work, we add to the idea of checked coverage an analysis of requirements coverage to help provide insight to engineers as to whether the requirements or the test suite need to be improved. We implement our approach based on a dynamic backward slicing technique and evaluate it on several systems developed in Simulink. The results of our preliminary study show that even for systems with comprehensive test suites and good sets of requirements, our approach can identify cases where more tests or more requirements are needed to improve coverage numbers.

Dynamic Slicing↗

Integrating FRET with Copilot: Automated Translation of Natural Language Requirements to Runtime Monitors

Runtime verification (RV) enables monitoring systems at runtime, to detect property violations early and limit their potential consequences. To provide the level of assurance required for ultra-critical systems, monitor specifications must faithfully reflect the original mission requirements, which are often written in ambiguous natural language. This paper presents an end-to-end framework to capture requirements in structured natural language and generate monitors that capture their semantics faithfully. We leverage NASA’s Formal Requirement Elicitation Tool (FRET), and the RV system Copilot. We extend FRET with mechanisms to capture additional information needed to generate monitors, and introduce OGMA, a new tool to bridge the gap between FRET and Copilot. With this framework, users can write requirements in an intuitive format and obtain real-time C monitors suitable for use in embedded systems. Our tool chain is available as open source.

FRET↗