SEARCH · Engineering Papers

Results for “engineered systems”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,243 records · Page 69

All sources NASA NTRS DOE OSTI

NASA NTRS2010

The ICARE Method

The ICARE method is a flexible, widely applicable method for systems engineers to solve problems and resolve issues in a complete and comprehensive manner. The method can be tailored by diverse users for direct application to their function (e.g. system integrators, design engineers, technical discipline leads, analysts, etc.). The clever acronym, ICARE, instills the attitude of accountability, safety, technical rigor and engagement in the problem resolution: Identify, Communicate, Assess, Report, Execute (ICARE). This method was developed through observation of Space Shuttle Propulsion Systems Engineering and Integration (PSE&I) office personnel approach in an attempt to succinctly describe the actions of an effective systems engineer. Additionally it evolved from an effort to make a broadly-defined checklist for a PSE&I worker to perform their responsibilities in an iterative and recursive manner. The National Aeronautics and Space Administration (NASA) Systems Engineering Handbook states, engineering of NASA systems requires a systematic and disciplined set of processes that are applied recursively and iteratively for the design, development, operation, maintenance, and closeout of systems throughout the life cycle of the programs and projects. ICARE is a method that can be applied within the boundaries and requirements of NASA s systems engineering set of processes to provide an elevated sense of duty and responsibility to crew and vehicle safety. The importance of a disciplined set of processes and a safety-conscious mindset increases with the complexity of the system. Moreover, the larger the system and the larger the workforce, the more important it is to encourage the usage of the ICARE method as widely as possible. According to the NASA Systems Engineering Handbook, elements of a system can include people, hardware, software, facilities, policies and documents; all things required to produce system-level results, qualities, properties, characteristics, functions, behavior and performance. The ICARE method can be used to improve all elements of a system and, consequently, the system-level functional, physical and operational performance. Even though ICARE was specifically designed for a systems engineer, any person whose job is to examine another person, product, or process can use the ICARE method to improve effectiveness, implementation, usefulness, value, capability, efficiency, integration, design, and/or marketability. This paper provides the details of the ICARE method, emphasizing the method s application to systems engineering. In addition, a sample of other, non-systems engineering applications are briefly discussed to demonstrate how ICARE can be tailored to a variety of diverse jobs (from project management to parenting).

Henke, Luke↗

DOE OSTI2022

An Introduction to Los Alamos National Laboratory [Slides]

The Weapon Systems Engineering Division (W) provides the system engineering and program management necessary to sustain the safety, reliability, and security of the Los Alamos National Laboratory’s assets in the active United States nuclear stockpile - the B61, W76, W78 and W88. The Division generates key certification data for Annual Assessment supporting the Laboratory Director's letter to the President on the health of those warheads. This role demands ongoing surveillance of the active stockpile and evaluation of the potential impact of any issues through design, engineering, fabrication, testing using state-of-the-art computational simulation tools and engineering test facilities. The Division works in close liaison with the several production facilities across the nuclear security complex as well as with the customers in the US Navy and Air Force.

98 NUCLEAR DISARMAMENT, SAFEGUARDS, AND PHYSICAL P↗

NASA NTRS1980

Advanced oxygen-hydrocarbon rocket engine study

The program consists of parametric analysis and design to provide a consistent engine system data base for defining advantages and disadvantages, system performance and operating limits, engine parametric data, and technology requirements for candidate high pressure LO2/Hydrocarbon engine systems. The parametric chamber and nozzle cooling analysis was completed for the four potential coolants: RP-1, LCH4, LO2, and LH2. A summary of the cooling capability of each propellant is presented.

Obrien, J. O.↗

NASA NTRS1984

Automotive Stirling Engine Development Program. RESD summary report

The design of reference Stirling engine system as well as the engine auxiliaries and controls is described. Manufacturing costs in production quantity are also presented. Engine system performance predictions are discussed and vehicle integration is developed, along with projected fuel economy levels.

Source record↗

NASA NTRS2005

Fast Algorithms for Model-Based Diagnosis

Two improved new methods for automated diagnosis of complex engineering systems involve the use of novel algorithms that are more efficient than prior algorithms used for the same purpose. Both the recently developed algorithms and the prior algorithms in question are instances of model-based diagnosis, which is based on exploring the logical inconsistency between an observation and a description of a system to be diagnosed. As engineering systems grow more complex and increasingly autonomous in their functions, the need for automated diagnosis increases concomitantly. In model-based diagnosis, the function of each component and the interconnections among all the components of the system to be diagnosed (for example, see figure) are represented as a logical system, called the system description (SD). Hence, the expected behavior of the system is the set of logical consequences of the SD. Faulty components lead to inconsistency between the observed behaviors of the system and the SD. The task of finding the faulty components (diagnosis) reduces to finding the components, the abnormalities of which could explain all the inconsistencies. Of course, the meaningful solution should be a minimal set of faulty components (called a minimal diagnosis), because the trivial solution, in which all components are assumed to be faulty, always explains all inconsistencies. Although the prior algorithms in question implement powerful methods of diagnosis, they are not practical because they essentially require exhaustive searches among all possible combinations of faulty components and therefore entail the amounts of computation that grow exponentially with the number of components of the system.

Fijany, Amir↗

NASA NTRS2017

Extension of MBSE for Project Programmatics Management on the Asteroid Redirect Robotic Mission

Model-based Systems Engineering can be employed beyond management of the technical architecture development of a system to also manage the programmatics associated with Systems Engineering activities of a project. On NASA’s Asteroid Redirect Robotic Mission, MBSE has been successfully employed to manage, generate, and interact with the documentation-based deliverables associated with System Engineering activities. This has been involved in defining and tracking project document, milestone, and personnel metadata via the same modeling framework used for the technical architecture management. Additionally, it has focused on improving overall user experiences through linkage of documentation to technical content in the system model, automation of manually intensive tasks, and others stakeholderoriented features.

Mozafari, Tanaz↗

NASA NTRS2009

Liquid Oxygen Rotating Friction Ignition Testing of Aluminum and Titanium with Monel and Inconel for Rocket Engine Propulsion System Contamination Investigation

Metallic contaminant was found in the liquid oxygen (LOX) pre-valve screen of the shuttle main engine propulsion system on two orbiter vehicles. To investigate the potential for an ignition, NASA Johnson Space Center White Sands Test Facility performed (modified) rotating friction ignition testing in LOX. This testing simulated a contaminant particle in the low-pressure oxygen turbo pump (LPOTP) and the high-pressure oxygen turbo pump (HPOTP) of the shuttle main propulsion system. Monel(R) K-500 and Inconel(R) 718 samples represented the LPOTP and HPOTP materials. Aluminum foil tape and titanium foil represented the contaminant particles. In both the Monel(R) and Inconel(R) material configurations, the aluminum foil tape samples did not ignite after 30 s of rubbing. In contrast, all of the titanium foil samples ignited regardless of the rubbing duration or material configuration. However, the titanium foil ignitions did not propagate to the Monel and Inconel materials.

Peralta, S.↗

NASA NTRS1978

A data management system for engineering and scientific computing

Data elements and relationship definition capabilities for this data management system are explicitly tailored to the needs of engineering and scientific computing. System design was based upon studies of data management problems currently being handled through explicit programming. The system-defined data element types include real scalar numbers, vectors, arrays and special classes of arrays such as sparse arrays and triangular arrays. The data model is hierarchical (tree structured). Multiple views of data are provided at two levels. Subschemas provide multiple structural views of the total data base and multiple mappings for individual record types are supported through the use of a REDEFINES capability. The data definition language and the data manipulation language are designed as extensions to FORTRAN. Examples of the coding of real problems taken from existing practice in the data definition language and the data manipulation language are given.

Elliot, L.↗

NASA NTRS2007

Hypothetical Scenario Generator for Fault-Tolerant Diagnosis

The Hypothetical Scenario Generator for Fault-tolerant Diagnostics (HSG) is an algorithm being developed in conjunction with other components of artificial- intelligence systems for automated diagnosis and prognosis of faults in spacecraft, aircraft, and other complex engineering systems. By incorporating prognostic capabilities along with advanced diagnostic capabilities, these developments hold promise to increase the safety and affordability of the affected engineering systems by making it possible to obtain timely and accurate information on the statuses of the systems and predicting impending failures well in advance. The HSG is a specific instance of a hypothetical- scenario generator that implements an innovative approach for performing diagnostic reasoning when data are missing. The special purpose served by the HSG is to (1) look for all possible ways in which the present state of the engineering system can be mapped with respect to a given model and (2) generate a prioritized set of future possible states and the scenarios of which they are parts.

James, Mark↗

NASA NTRS2016

Exposing Hidden Parts of the SE Process: MBSE Patterns and Tools for Tracking and Traceability

An interesting benefit of applying Model-Based Systems Engineering (MBSE) is that the rigor and coordination intrinsic to MBSE forces us to apply Systems Engineering to our own traditional activities, processes, and products, which results in richer, more expressive models, more powerful reasoning, and a clearer and more effective Systems Engineering (SE) process. Our MBSE frameworks and languages contain semantic richness sufficient to describe our systems at any particular point in time, often with an emphasis on the description of the system at major milestones. This is unarguably a real asset. However, when we apply MBSE in service of missions that are in development, rapidly evolving, of a larger scale, and where interpersonal communication is a critical part of the design process, we discover that our frameworks and languages are still not quite rich enough to enable us to ask the kinds of questions and get the kinds of answers we want in order to address the concerns of day to day work. This paper will discuss some patterns and tools we have developed to help address some of the not-always-explicit SE concerns that we have identified through our MBSE work. Particularly, this paper will discuss flexible yet practical methods for defining and capturing maturity, workflow, and agreement traceability within our system models, extensible ways to perform and track model audits, and ways to report and interact with this knowledge in the context of MBSE applied to support NASA’s Europa Project.

Jackson, Maddalena↗

NASA NTRS2016

Exposing Hidden Parts of the SE Process: MBSE Patterns and Tools for Tracking and Traceability

Jackson, Maddalena↗

NASA NTRS1983

Comparison of Results Obtained from Flight Tests and Simulated Tests of a Digital Electronic Engine Control System in an F-15 Airplane

Substantial benefits of a full authority digital electronic engine control on an air breathing engine were demonstrated repeatedly in simulation studies, ground engine tests, and engine altitude test facilities. A digital engine electronic control system showed improvements in efficiency, performance, and operation. An additional benefit of full authority digital controls is the capability of detecting and correcting failures and providing engine health diagnostics.

Myers, Lawrence P.↗

NASA NTRS2011

NASA System Safety Handbook: System Safety Framework and Concepts for Implementation - Volume 1

System safety assessment is defined in NPR 8715.3C, NASA General Safety Program Requirements as a disciplined, systematic approach to the analysis of risks resulting from hazards that can affect humans, the environment, and mission assets. Achievement of the highest practicable degree of system safety is one of NASA's highest priorities. Traditionally, system safety assessment at NASA and elsewhere has focused on the application of a set of safety analysis tools to identify safety risks and formulate effective controls.1 Familiar tools used for this purpose include various forms of hazard analyses, failure modes and effects analyses, and probabilistic safety assessment (commonly also referred to as probabilistic risk assessment (PRA)). In the past, it has been assumed that to show that a system is safe, it is sufficient to provide assurance that the process for identifying the hazards has been as comprehensive as possible and that each identified hazard has one or more associated controls. The NASA Aerospace Safety Advisory Panel (ASAP) has made several statements in its annual reports supporting a more holistic approach. In 2006, it recommended that "... a comprehensive risk assessment, communication and acceptance process be implemented to ensure that overall launch risk is considered in an integrated and consistent manner." In 2009, it advocated for "... a process for using a risk-informed design approach to produce a design that is optimally and sufficiently safe." As a rationale for the latter advocacy, it stated that "... the ASAP applauds switching to a performance-based approach because it emphasizes early risk identification to guide designs, thus enabling creative design approaches that might be more efficient, safer, or both." For purposes of this preface, it is worth mentioning three areas where the handbook emphasizes a more holistic type of thinking. First, the handbook takes the position that it is important to not just focus on risk on an individual basis but to consider measures of aggregate safety risk and to ensure wherever possible that there be quantitative measures for evaluating how effective the controls are in reducing these aggregate risks. The term aggregate risk, when used in this handbook, refers to the accumulation of risks from individual scenarios that lead to a shortfall in safety performance at a high level: e.g., an excessively high probability of loss of crew, loss of mission, planetary contamination, etc. Without aggregated quantitative measures such as these, it is not reasonable to expect that safety has been optimized with respect to other technical and programmatic objectives. At the same time, it is fully recognized that not all sources of risk are amenable to precise quantitative analysis and that the use of qualitative approaches and bounding estimates may be appropriate for those risk sources. Second, the handbook stresses the necessity of developing confidence that the controls derived for the purpose of achieving system safety not only handle risks that have been identified and properly characterized but also provide a general, more holistic means for protecting against unidentified or uncharacterized risks. For example, while it is not possible to be assured that all credible causes of risk have been identified, there are defenses that can provide protection against broad categories of risks and thereby increase the chances that individual causes are contained. Third, the handbook strives at all times to treat uncertainties as an integral aspect of risk and as a part of making decisions. The term "uncertainty" here does not refer to an actuarial type of data analysis, but rather to a characterization of our state of knowledge regarding results from logical and physical models that approximate reality. Uncertainty analysis finds how the output parameters of the models are related to plausible variations in the input parameters and in the modeling assumptions. The evaluation of unrtainties represents a method of probabilistic thinking wherein the analyst and decision makers recognize possible outcomes other than the outcome perceived to be "most likely." Without this type of analysis, it is not possible to determine the worth of an analysis product as a basis for making decisions related to safety and mission success. In line with these considerations the handbook does not take a hazard-analysis-centric approach to system safety. Hazard analysis remains a useful tool to facilitate brainstorming but does not substitute for a more holistic approach geared to a comprehensive identification and understanding of individual risk issues and their contributions to aggregate safety risks. The handbook strives to emphasize the importance of identifying the most critical scenarios that contribute to the risk of not meeting the agreed-upon safety objectives and requirements using all appropriate tools (including but not limited to hazard analysis). Thereafter, emphasis shifts to identifying the risk drivers that cause these scenarios to be critical and ensuring that there are controls directed toward preventing or mitigating the risk drivers. To address these and other areas, the handbook advocates a proactive, analytic-deliberative, risk-informed approach to system safety, enabling the integration of system safety activities with systems engineering and risk management processes. It emphasizes how one can systematically provide the necessary evidence to substantiate the claim that a system is safe to within an acceptable risk tolerance, and that safety has been achieved in a cost-effective manner. The methodology discussed in this handbook is part of a systems engineering process and is intended to be integral to the system safety practices being conducted by the NASA safety and mission assurance and systems engineering organizations. The handbook posits that to conclude that a system is adequately safe, it is necessary to consider a set of safety claims that derive from the safety objectives of the organization. The safety claims are developed from a hierarchy of safety objectives and are therefore hierarchical themselves. Assurance that all the claims are true within acceptable risk tolerance limits implies that all of the safety objectives have been satisfied, and therefore that the system is safe. The acceptable risk tolerance limits are provided by the authority who must make the decision whether or not to proceed to the next step in the life cycle. These tolerances are therefore referred to as the decision maker's risk tolerances. In general, the safety claims address two fundamental facets of safety: 1) whether required safety thresholds or goals have been achieved, and 2) whether the safety risk is as low as possible within reasonable impacts on cost, schedule, and performance. The latter facet includes consideration of controls that are collective in nature (i.e., apply generically to broad categories of risks) and thereby provide protection against unidentified or uncharacterized risks.

Dezfuli, Homayoon↗

NASA NTRS1985

Design of an expert-system flight status monitor

The modern advanced avionics in new high-performance aircraft strains the capability of current technology to safely monitor these systems for flight test prior to their generalized use. New techniques are needed to improve the ability of systems engineers to understand and analyze complex systems in the limited time available during crucial periods of the flight test. The Dryden Flight Research Facility of NASA's Ames Research Center is involved in the design and implementation of an expert system to provide expertise and knowledge to aid the flight systems engineer. The need for new techniques in monitoring flight systems and the conceptual design of an expert-system flight status monitor is discussed. The status of the current project and its goals are described.

Regenie, V. A.↗

NASA NTRS2016

Effect of Satellite Formations and Imaging Modes on Global Albedo Estimation

We confirm the applicability of using small satellite formation flight for multi-angular earth observation to retrieve global, narrow band, narrow field-of-view albedo. The value of formation flight is assessed using a coupled systems engineering and science evaluation model, driven by Model Based Systems Engineering and Observing System Simulation Experiments. Albedo errors are calculated against bi-directional reflectance data obtained from NASA airborne campaigns made by the Cloud Absorption Radiometer for the seven major surface types, binned using MODIS' land cover map - water, forest, cropland, grassland, snow, desert and cities. A full tradespace of architectures with three to eight satellites, maintainable orbits and imaging modes (collective payload pointing strategies) are assessed. For an arbitrary 4-sat formation, changing the reference, nadir-pointing satellite dynamically reduces the average albedo error to 0.003, from 0.006 found in the static reference case. Tracking pre-selected waypoints with all the satellites reduces the average error further to 0.001, allows better polar imaging and continued operations even with a broken formation. An albedo error of 0.001 translates to 1.36 W/sq m or 0.4% in Earth's outgoing radiation error. Estimation errors are found to be independent of the satellites' altitude and inclination, if the nadir-looking is changed dynamically. The formation satellites are restricted to differ in only right ascension of planes and mean anomalies within slotted bounds. Three satellites in some specific formations show average albedo errors of less than 2% with respect to airborne, ground data and seven satellites in any slotted formation outperform the monolithic error of 3.6%. In fact, the maximum possible albedo error, purely based on angular sampling, of 12% for monoliths is outperformed by a five-satellite formation in any slotted arrangement and an eight satellite formation can bring that error down four fold to 3%. More than 70% ground spot overlap between the satellites is possible with 0.5deg of pointing accuracy, 2 Km of GPS accuracy and commands uplinked once a day. The formations can be maintained at less than 1 m/s of monthly (Delta)V per satellite.

BRDF↗

NASA NTRSDate not supplied

Development of a Human Systems Integration Plan

NASA defines Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The HSI Plan defines how HSI activities will be implemented across the lifecycle of the mission, as required by NPR 7123.1C, NASA Systems Engineering Processes and Requirements, and NPR 8705.2C Human-Rating Requirements for Space Systems. The goal of this presentation is to share with government and industry how an HSI Plan can be implemented. The presentation will cover HSI implementation for flight systems, vehicle processing, and interfaces. These are divided into six NASA HSI Domains: human factors engineering, operations resources, safety, training, maintainability and supportability, habitability and environment. HSI activities go across the mission’s lifecycle from pre-formulation and acquisition through design, development, operations, maintenance, and decommissioning. The HSI Plan includes a description of the HSI activities and products that are essential for human rating, operability, maintainability, supportability, and affordability of the mission systems. It also describes the role of the HSI Team required as part of the Human Rating process. The HSI Plan utilizes the operational expertise within NASA to ensure designs and testing are successful, leading to acceptable human spaceflight vehicles.

Jackelynne Silva-Martinez↗

DOE OSTI2026

FY24 Status of Engineered Barrier Systems Research

This report describes research and development (R&D) activities conducted during Fiscal Year 2024 (FY24) specifically related to the Engineered Barrier System (EBS) R&D Work Package in the Spent Fuel and High-Level Waste Disposition Campaign supported by the United States (U.S.) Department of Energy (DOE). The R&D activities focus on understanding EBS component evolution and interactions within the EBS, as well as interactions between the host media and the EBS. The R&D team represented in this report consists of individuals from Sandia National Laboratories, Lawrence Berkeley National Laboratory (LBNL), Los Alamos National Laboratory (LANL), and Vanderbilt University. EBS R&D work also leverages international collaborations to ensure that the DOE program is active and abreast of the latest advances in nuclear waste disposal.

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

NASA NTRS2000

Goals Analysis Procedure Guidelines for Applying the Goals Analysis Process

One of the key elements to successful project management is the establishment of the "right set of requirements", requirements that reflect the true customer needs and are consistent with the strategic goals and objectives of the participating organizations. A viable set of requirements implies that each individual requirement is a necessary element in satisfying the stated goals and that the entire set of requirements, taken as a whole, is sufficient to satisfy the stated goals. Unfortunately, it is the author's experience that during project formulation phases' many of the Systems Engineering customers do not conduct a rigorous analysis of the goals and objectives that drive the system requirements. As a result, the Systems Engineer is often provided with requirements that are vague, incomplete, and internally inconsistent. To complicate matters, most systems development methodologies assume that the customer provides unambiguous, comprehensive and concise requirements. This paper describes the specific steps of a Goals Analysis process applied by Systems Engineers at the NASA Langley Research Center during the formulation of requirements for research projects. The objective of Goals Analysis is to identify and explore all of the influencing factors that ultimately drive the system's requirements.

Motley, Albert E., III↗