Engineering Papers⌕ Search

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.

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

At least 451 records · Page 25

An Analog Computer Study of the Low-Frequency Flow Dynamics of Two Nuclear-Rocket Cold-Flow Engine Systems

An analog computer study is made of the low-frequency flow dynamics observed with liquid hydrogen flowing in two different nuclear-rocket cold-flow (unfueled) engine systems. The prediction of the low-frequency response depends largely upon the generation of the proper mass-flow storage in the system. This is achieved by relating, in the model lumping, the average values of fluid enthalpy and a certain thermodynamic fluid property. A two-phase state equation is derived for thermodynamic equilibrium between the gas and liquid phases. Parametric studies are made which demonstrate the effect of the pump characteristics on the flow damping.

Fox, Harry W., Jr.↗

Systems Engineering Using Heritage Spacecraft Technology: Lessons Learned from Discovery and New Frontiers Deep Space Missions

In the design and development of complex spacecraft missions, project teams frequently assume the use of advanced technology or heritage systems to enable a mission or reduce the overall mission risk and cost. As projects proceed through the development life cycle, increasingly detailed knowledge of the advanced or heritage systems and the system environment identifies unanticipated issues that result in cost overruns or schedule impacts. The Discovery & New Frontiers (D&NF) Program Office recently studied cost overruns and schedule delays resulting from advanced technology or heritage assumptions for 6 D&NF missions. The goal was to identify the underlying causes for the overruns and delays, and to develop practical mitigations to assist the D&NF projects in identifying potential risks and controlling the associated impacts to proposed mission costs and schedules. The study found that the cost and schedule growth did not result from technical hurdles requiring significant technology development. Instead, systems engineering processes did not identify critical issues early enough in the design cycle to ensure project schedules and estimated costs address the inherent risks. In general, the overruns were traceable to: inadequate understanding of the heritage system s behavior within the proposed spacecraft design and mission environment; an insufficient level of experience with the heritage system; or an inadequate scoping of the system-wide impacts necessary to implement the heritage or advanced technology. This presentation summarizes the study s findings and offers suggestions for improving the project s ability to identify and manage the risks inherent in the technology and heritage design solution.

Barley, Bryan↗

Habitable Exoplanet Observatory (HabEx) Telescope: Systems Engineering and STOP Modeling

The Habitable Exoplanet Observatory Mission (HabEx) is one of four missions studied for the 2020 Astrophysics Decadal Survey. Its goal is to directly image and spectroscopically characterize planetary systems in the habitable zone around nearby sun-like stars. Additionally, HabEx will perform a broad range of general astrophysics science enabled by 115 to 1700 nm spectral range and 3 x 3 arc-minute FOV. Critical to achieving its science goals is a large, ultra-stable UV/Optical/Near-IR (UVOIR) telescope. The baseline HabEx telescope is a 4-meter off-axis unobscured three-mirror-anastigmatic, diffraction limited at 400 nm with wavefront stability on the order of a few 10s of picometers. This paper summarizes the opto-mechanical design of the baseline optical telescope assembly, including a discussion of how we applied science driven systems engineering to derive the telescope’s engineering specifications from the mission’s science requirements, and presents analysis that the baseline telescope structure meets its specified tolerances.

Stahl, H. Philip↗

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

Mars 2020 Model Based Systems Engineering Pilot

The pilot study is led by the Integration Engineering group in NASA's Launch Services Program (LSP). The Integration Engineering (IE) group is responsible for managing the interfaces between the spacecraft and launch vehicle. This pilot investigates the utility of Model-Based Systems Engineering (MBSE) with respect to managing and verifying interface requirements. The main objectives of the pilot are to model several key aspects of the Mars 2020 integrated operations and interface requirements based on the design and verification artifacts from Mars Science Laboratory (MSL) and to demonstrate how MBSE could be used by LSP to gain further insight on the interface between the spacecraft and launch vehicle as well as to enhance how LSP manages the launch service. The method used to accomplish this pilot started through familiarization of SysML, MagicDraw, and the Mars 2020 and MSL systems through books, tutorials, and NASA documentation. MSL was chosen as the focus of the model since its processes and verifications translate easily to the Mars 2020 mission. The study was further focused by modeling specialized systems and processes within MSL in order to demonstrate the utility of MBSE for the rest of the mission. The systems chosen were the In-Flight Disconnect (IFD) system and the Mass Properties process. The IFD was chosen as a system of focus since it is an interface between the spacecraft and launch vehicle which can demonstrate the usefulness of MBSE from a system perspective. The Mass Properties process was chosen as a process of focus since the verifications for mass properties occur throughout the lifecycle and can demonstrate the usefulness of MBSE from a multi-discipline perspective. Several iterations of both perspectives have been modeled and evaluated. While the pilot study will continue for another 2 weeks, pros and cons of using MBSE for LSP IE have been identified. A pro of using MBSE includes an integrated view of the disciplines, requirements, and verifications leading up to launch. The model allows IE to understand the relationships between disciplines throughout test activities and verifications. Additionally, the relationships between disciplines and integration tasks are generally consistent. The model allows for the generic relationships and tasks to be captured and used throughout multiple mission models should LSP further pursue MBSE. A con of MBSE is the amount of time it takes upfront to understand MBSE and create a useful model. The upfront time it takes to create a useful model is heavily discussed in MBSE literature and is a consistent con throughout the known applications of MBSE. The need to understand SysML and the software chosen also poses the possibility of a "bottleneck" or one person being the sole MBSE user for the working group. The utility of MBSE will continue to be evaluated through the remainder of the study. In conclusion, the original objectives of the pilot study were to use artifacts from MSL to model key aspects of Mars 2020 and demonstrate how MBSE could be used by LSP to gain insight into the spacecraft and launch vehicle interfaces. Progress has been made in modeling and identifying the utility of MBSE to LSP IE and will continue to be made until the pilot study's conclusion in mid-August. The results of this study will produce initial models, modeling instructions and examples, and a summary of MBSE's utility for future use by LSP.

Dukes, Alexandra Marie↗

Systems Engineering Management Plan NASA Traffic Aware Planner Integration Into P-180 Airborne Test-Bed

NASA's Traffic Aware Planner (TAP) is a cockpit decision support tool that provides aircrew with vertical and lateral flight-path optimizations with the intent of achieving significant fuel and time savings, while automatically avoiding traffic, weather, and restricted airspace conflicts. A key step towards the maturation and deployment of TAP concerned its operational evaluation in a representative flight environment. This Systems Engineering Management Plan (SEMP) addresses the test-vehicle design, systems integration, and flight-test planning for the first TAP operational flight evaluations, which were successfully completed in November 2013. The trial outcomes are documented in the Traffic Aware Planner (TAP) flight evaluation paper presented at the 14th AIAA Aviation Technology, Integration, and Operations Conference, Atlanta, GA. (AIAA-2014-2166, Maris, J. M., Haynes, M. A., Wing, D. J., Burke, K. A., Henderson, J., & Woods, S. E., 2014).

Maris, John↗

Space station System Engineering and Integration (SE and I). Volume 2: Study results

A summary of significant study results that are products of the Phase B conceptual design task are contained. Major elements are addressed. Study results applicable to each major element or area of design are summarized and included where appropriate. Areas addressed include: system engineering and integration; customer accommodations; test and program verification; product assurance; conceptual design; operations and planning; technical and management information system (TMIS); and advanced development.

Source record↗

A Systems Engineering Approach to Quality Assurance for Aerospace Testing

On the surface, it appears that AS9100 has little to say about how to apply a Quality Management System (QMS) to major aerospace test programs (or even smaller ones). It also appears that there is little in the quality engineering Body of Knowledge (BOK) that applies to testing, unless it is nondestructive examination (NDE), or some type of lab or bench testing associated with the manufacturing process. However, if one examines: a) how the systems engineering (SE) processes are implemented throughout a test program; and b) how these SE processes can be mapped to the requirements of AS9100, a number of areas for involvement of the quality professional are revealed. What often happens is that quality assurance during a test program is limited to inspections of the test article; what could be considered a manufacturing al fresco approach. This limits the quality professional and is a disservice to the programs and projects, since there are a number of ways that quality can enhance critical processes, and support efforts to improve risk reduction, efficiency and effectiveness. The Systems Engineering (SE) discipline is widely used in aerospace to ensure the progress from Stakeholder Expectations (the President, Congress, the taxpayers) to a successful, delivered product or service. Although this is well known, what is not well known is that these same SE processes are implemented in varying complexity, to prepare for and implement test projects that support research, development, verification and validation, qualification, and acceptance test projects. Although the test organization's terminology may vary from the SE terminology, and from one test service provider to another, the basic process is followed by successful, reliable testing organizations. For this analysis, NASA Procedural Requirements (NPR) 7123.1, NASA Systems Engineering Processes and Requirements is used to illustrate the SE processes that are used for major aerospace testing. Many of these processes are also implemented for smaller test projects, and this set of processes will also look familiar to those who have participated in launch site activation and flight demonstrations.

Shepherd, Christena C.↗

A contemporary view of systems engineering

The concept of a 'system' is defined, and the 'systems approach' is discussed. Four contemporary examples of the systems approach are presented: an operations research project, the planning-programming-budgeting system, an information processing system, and aerospace programs.

Miles, R. F., Jr.↗

Intelligent Engine Systems

A high bypass jet engine fan case represents one of the largest, heaviest single components in an engine. In addition to supporting the inlet and providing the fan flowpath, the most critical function is the containment of a failed fan blade. In this development program, a lightweight, low-cost composite containment case with diagnostic capabilities was developed, fabricated, and tested. The fan case design, containment methods, and diagnostic concepts evaluated in the initial Propulsion 21 program were improved and scaled up to a full case design.

Xie, Ming↗

Evaluation of Recent Upgrades to the NESS (Nuclear Engine System Simulation) Code

The Nuclear Thermal Rocket (NTR) concept is being evaluated as a potential propulsion technology for exploratory expeditions to the moon, Mars, and beyond. The need for exceptional propulsion system performance in these missions has been documented in numerous studies, and was the primary focus of a considerable effort undertaken during the Rover/NERVA program from 1955 to 1973. The NASA Glenn Research Center is leveraging this past NTR investment in their vehicle concepts and mission analysis studies with the aid of the Nuclear Engine System Simulation (NESS) code. This paper presents the additional capabilities and upgrades made to this code in order to perform higher fidelity NTR propulsion system analysis and design, and a comparison of its results to the Small Nuclear Rocket Engine (SNRE) design.

Fittje, James E.↗

AP233: An Information Model for Systems Engineering

In today's world, information is abundant. We have no problems generating it. But we are challenged to find, organize, and exchange information. center dot A standardized model of information can help. Such a model nearly completed its development for Systems Engineering. It is referred to as AP233 (AP = Application Protocol).

Siebes, Georg↗

The Use of Human Modeling of EVA Tasks as a Systems Engineering Tool

Computer-generated human models have been used in aerospace design for a decade. They have come to be highly reliable for worksite analysis of certain types of EVA tasks. In many design environments, this analysis comes after the structural design is largely complete. However, the use of these models as a development tool is gaining acceptance within organizations that practice good systems engineering processes. The design of the United States Propulsion Module for the International Space Station provides an example of this application. The Propulsion Module will provide augmentation to the propulsion capability supplied by the Russian Service Module Zvezda. It is a late addition to the set of modules provided by the United States to the ISS Program, and as a result, faces design challenges that result from the level of immaturity of its integration into the Station. Among these are heat dissipation and physical envelopes. Since the rest of the Station was designed to maximize the use of the cooling system, little margin is available for the addition of another module. The Propulsion Module will attach at the forward end of the Station, and will be between the Orbiter and the rest of ISS. Since cargo must be removed from the Payload Bay and transferred to Station by the Canadarm, there is a potential for protrusions from the module, such as thruster booms, to interfere with robotic operations. These and similar engineering issues must be addressed as part of the development. In the implementation of good system design, all design solutions should be analyzed for compatibility with all affected subsystems. Human modeling has been used in this project to provide rapid input to system trades of design concepts. For example, the placement of radiators and avionics components for optimization of heat dissipation had to be examined for feasibility of EVA translation paths and worksite development. Likewise, the location of and mechanism for the retraction of thruster booms was partly driven by available Orbiter, robotic arm, and other module envelopes; worksite analysis was required for early assessment of task success. Since these trade studies included the EVA analysis as part of the decision criteria, the design had a high degree of assurance of EVA supportability from the outset. This approach contributes greatly to mission success.

Dischinger, H. Charles, Jr.↗

Harnessing Systems Engineering Methodology in Using Earth Science Research Data for Real Applications

For the last three decades, Earth science remote sensing technologies have been providing an enormous amount of useful data and information serving to broaden our understanding of the home planet as a system. NASA's Earth science program has deployed about 18 complex satellites and is in the process of defining and launching multiple observing systems in this decade. At the same time, the European Community and many other countries such as Russia, France, India, Japan, and China have also significantly contributed to Earth science research. To date, the majority of such efforts have concentrated on expanding our scientific understanding of the multiple nonlinear and chaotic processes of Earth's behavior. In recent years, legislators and stakeholders have put serious pressure on the science community to devote more attention to making use of scientific results for societal benefit. For instance, there are a number of areas such as energy forecasting, aviation safety, agricultural efficiency, disaster management, air quality and public health that can directly take advantage of Earth science results to analyze and predict large scale problems and conditions. This is becoming even more important now that we live in a global economy interconnected via the internet and transportation systems; regional environmental conditions can have far reaching impact across continental boundaries. These factors dictate requirements for global data that can help us assess and control the devastating problems of famine, water resources, wildfires, human health and more. To do this requires a serious, organized, and systematic approach that transfers fundamental research products to the applied sciences domain. This paper presents a systems engineering and management process that can effectively make such transfer of data to the user community. Examples are presented on how the above decision making framework can help in solving critical problems such as the spread of vector borne diseases, forecasts of harmful algal blooms as well as forest fires and wildfires, and the intercontinental transport of dust storms and pollution.

Habib, Shahid↗

Program Promotion Can Distort Space Systems Engineering and Deny Risk

NASA's spectacular success in the Apollo moon landings was achieved against the odds by an obsessive dedication to reducing the great risk. But risk analysis predicted so many astronaut fatalities that it was thought to be unreasonably pessimistic and potentially damaging to the Apollo program. Risk analysis was discontinued, risk was neglected in space shuttle engineering, and so the space shuttle design was unnecessarily dangerous. Since the Apollo era it has been understood that long human space missions would recycle oxygen and water to avoid the very high launch cost of directly supplying them. The development of recycling systems was justified by the need to increase material closure and reduce launch mass. When it was recognized that increasing closure leads to rapidly diminishing returns, the program goal was changed to reducing launch mass and reliability, cost, and risk were considered irrelevant. Systems engineering and especially the discouraging problems of risk and cost have been deliberately ignored because they detract from program promotion, with unfortunate results. Current human launch system design does account for risk and the result strongly resembles Apollo. Current life support design continues to assume recycling, even though the recent great reduction in launch cost now allows direct supply of oxygen and water with significantly better quality, reliability, cost, and risk.

Advocacy↗