Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “risk management flight projects”

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 145 records · Page 8

NASA Applied Sciences Program

Goal 1: Enhance Applications Research Advance the use of NASA Earth science in policy making, resource management and planning, and disaster response. Key Actions: Identify priority needs, conduct applied research to generate innovative applications, and support projects that demonstrate uses of NASA Earth science. Goal 2: Increase Collaboration Establish a flexible program structure to meet diverse partner needs and applications objectives. Key Actions: Pursue partnerships to leverage resources and risks and extend the program s reach and impact. Goal 3:Accelerate Applications Ensure that NASA s flight missions plan for and support applications goals in conjunction with their science goals, starting with mission planning and extending through the mission life cycle. Key Actions: Enable identification of applications early in satellite mission lifecycle and facilitate effective ways to integrate end-user needs into satellite mission planning

Irwin, Daniel↗

Design and Development of a 200-kW Turbo-Electric Distributed Propulsion Testbed

There a few NASA funded electric and hybrid electric projects from different NASA Centers, including the NASA Armstrong Flight Research Center (AFRC) (Edwards, California). Each project identifies a specific technology gap that is currently inhibiting the growth and proliferation of relevant technologies in commercial aviation. This paper describes the design and development of a turbo-electric distributed propulsion (TeDP) hardware-in-the-loop (HIL) simulation bench, which is a test bed for discovering turbo-electric control, distributed electric control, power management control, and integration competencies while providing risk mitigation for future turbo-electric flying demonstrators.

propulsion↗

NASA's System-Wide Safety...A New Era in Aviation is Here!

NASA’s System-Wide Safety project is developing the concept and requirements for an assured In-Time Aviation Safety Management System (IASMS) that will: Improve the efficiency of flight, the access to airspace, and the expansion of services provided by air vehicles; Explore, discover, and understand the impact on safety from growing complexity introduced by industry modernization; Develop and demonstrate innovative solutions that enable the aviation transformation envisioned for global airspace system; Identify and proactively mitigate risks in accordance with target levels of safety; Assure safe, rapid, and repeatable access to a transformed National Airspace System (NAS)

Kyle Ellis↗

X-Plane Knowledge Capture Workshop Summary Report

The history of experimental aircraft research and development at the National Aeronautics and Space Administration (NASA) provides a large body of work for current and future team members to learn from and apply. NASA values the knowledge it gains from all the research it performs and desires to have that knowledge grow with each new project, incrementally adding to the collective knowledge base. To support this knowledge growth and sharing, in May 2019, NASA convened over 60 engineers; researchers; and other personnel (internal and external to NASA) for the X-plane1 Knowledge Capture Workshop to discuss their over 50-years’ worth of experiences in developing, operating, and managing experimental aircraft. Over the course of a two-day workshop, the group not only focused, primarily, on current X-plane development but also discussed a wide range of topics about experimental aircraft and flight research. In addition to the discussions, senior NASA aeronautics leaders shared their personal lessons learned with the workshop audience. Broadly, these discussions centered around the topics of organizational and cultural practices, the project lifecycle, flight, and risk and safety. Many of the observations offered by participants are applicable to other NASA team-based projects, demonstrating the value in sharing lessons learned and best practices across projects regardless of their research focus. To share the most valuable lessons learned as broadly as possible, a summary of these discussions has been compiled into the following report. These discussions are mostly included in their entirety, with some light editing for clarity and privacy. NASA is sharing this knowledge internally and making it available to the public in hopes that others can learn from the experimental aircraft challenges and successes at NASA. Note: this document represents the perspectives, experiences, and opinions of others but does not necessarily represent the official view of NASA.

Steven R Hirshorn↗

Engineering and Safety Partnership Enhances Safety of the Space Shuttle Program (SSP)

Project Management must use the risk assessment documents (RADs) as tools to support their decision making process. Therefore, these documents have to be initiated, developed, and evolved parallel to the life of the project. Technical preparation and safety compliance of these documents require a great deal of resources. Updating these documents after-the-fact not only requires substantial increase in resources - Project Cost -, but this task is also not useful and perhaps an unnecessary expense. Hazard Reports (HRs), Failure Modes and Effects Analysis (FMEAs), Critical Item Lists (CILs), Risk Management process are, among others, within this category. A positive action resulting from a strong partnership between interested parties is one way to get these documents and related processes and requirements, released and updated in useful time. The Space Shuttle Program (SSP) at the Marshall Space Flight Center has implemented a process which is having positive results and gaining acceptance within the Agency. A hybrid Panel, with equal interest and responsibilities for the two larger organizations, Safety and Engineering, is the focal point of this process. Called the Marshall Safety and Engineering Review Panel (MSERP), its charter (Space Shuttle Program Directive 110 F, April 15, 2005), and its Operating Control Plan emphasizes the technical and safety responsibilities over the program risk documents: HRs; FMEA/CILs; Engineering Changes; anomalies/problem resolutions and corrective action implementations, and trend analysis. The MSERP has undertaken its responsibilities with objectivity, assertiveness, dedication, has operated with focus, and has shown significant results and promising perspectives. The MSERP has been deeply involved in propulsion systems and integration, real time technical issues and other relevant reviews, since its conception. These activities have transformed the propulsion MSERP in a truly participative and value added panel, making a difference for the safety of the Space Shuttle Vehicle, its crew, and personnel. Because of the MSERP's valuable contribution to the assessment of safety risk for the SSP, this paper also proposes an enhanced Panel concept that takes this successful partnership concept to a higher level of 'true partnership'. The proposed panel is aimed to be responsible for the review and assessment of all risk relative to Safety for new and future aerospace and related programs.

Duarte, Alberto↗

V&V on a NASA Technology Demonstration Project: Low Density Supersonic Decelerator

Given their smaller budgets, but higher allowed risk posture, technology demonstration missions face different Verification and Validation (V&V) challenges than typical NASA missions. Despite these challenges, the Low Density Supersonic Decelerator (LDSD) project, managed by NASA’s Jet Propulsion Laboratory (JPL), has been extremely successful in testing new supersonic atmospheric decelerator technologies. A contribution to the project’s success is the unique V&V program that emphasized efficiency and flexibility. This paper will provide an overview of LDSD test objectives, Supersonic Flight Dynamics Tests (SFDT) performed so far, unique requirements structure and V&V processes implemented. The paper will focus on the V&V of the SFDT test architecture. Furthermore, lessons learned will also be presented at the end of the paper to aid future technology demonstration projects.

Murry, Michael L.↗

Purpose, Principles, and Challenges of the NASA Engineering and Safety Center

NASA formed the NASA Engineering and Safety Center in 2003 following the Space Shuttle Columbia accident. It is an Agency level, program-independent engineering resource supporting NASA's missions, programs, and projects. It functions to identify, resolve, and communicate engineering issues, risks, and, particularly, alternative technical opinions, to NASA senior management. The goal is to help ensure fully informed, risk-based programmatic and operational decision-making processes. To date, the NASA Engineering and Safety Center (NESC) has conducted or is actively working over 600 technical studies and projects, spread across all NASA Mission Directorates, and for various other U.S. Government and non-governmental agencies and organizations. Since inception, NESC human spaceflight related activities, in particular, have transitioned from Shuttle Return-to-Flight and completion of the International Space Station (ISS) to ISS operations and Orion Multi-purpose Crew Vehicle (MPCV), Space Launch System (SLS), and Commercial Crew Program (CCP) vehicle design, integration, test, and certification. This transition has changed the character of NESC studies. For these development programs, the NESC must operate in a broader, system-level design and certification context as compared to the reactive, time-critical, hardware specific nature of flight operations support.

Gilbert, Michael G.↗

What You Need to Know about Planetary Protection Categorization for Your Mission

Planetary protection mission categorization helps to define the risk posture for requirements definition and implementation practices on space flight projects with planetary protection considerations. NASA has recently updated it’s planetary protection policy (NPR 8715.24), and with the update comes a major change in how the planetary protection categorization process is performed for NASA missions. Previously, projects would request the NASA Planetary Protection Officer (PPO) provide a categorization letter documenting the planetary protection category assigned to the proposed mission. Under the new policy the project manager (PM) proposes the planetary protection category for their mission. Depending on the level of the category, the PPO either concurs or recommends concurrence to the Chief of Safety and Mission Assurance (SMA) before forwarding to the Mission Directorate Associate Administrator (MDAA) for final approval prior to the system requirements review (SRR). But what topics must be considered for categorization? This presentation will provide key considerations for planetary protection mission categorization including the target solar system body to be explored, the trajectory to get to the target body, and the operations to be performed at the target body. Additional unique scenarios such as secondary and auxiliary payloads, encountering other solar system bodies on the way to the target body, and sample return missions will also be discussed to share lessons learned from missions that have been through the new categorization process.

Elaine Seasly↗

Cassini Information Management System in Distributed Operations Collaboration and Cassini Science Planning

Launched on October 15, 1997, the Cassini-Huygens spacecraft began its ambitious journey to the Saturnian system with a complex suite of 12 scientific instruments, and another 6 instruments aboard the European Space Agencies Huygens Probe. Over the next 6 1/2 years, Cassini would continue its relatively simplistic cruise phase operations, flying past Venus, Earth, and Jupiter. However, following Saturn Orbit Insertion (SOI), Cassini would become involved in a complex series of tasks that required detailed resource management, distributed operations collaboration, and a data base for capturing science objectives. Collectively, these needs were met through a web-based software tool designed to help with the Cassini uplink process and ultimately used to generate more robust sequences for spacecraft operations. In 2001, in conjunction with the Southwest Research Institute (SwRI) and later Venustar Software and Engineering Inc., the Cassini Information Management System (CIMS) was released which enabled the Cassini spacecraft and science planning teams to perform complex information management and team collaboration between scientists and engineers in 17 countries. Originally tailored to help manage the science planning uplink process, CIMS has been actively evolving since its inception to meet the changing and growing needs of the Cassini uplink team and effectively reduce mission risk through a series of resource management validation algorithms. These algorithms have been implemented in the web-based software tool to identify potential sequence conflicts early in the science planning process. CIMS mitigates these sequence conflicts through identification of timing incongruities, pointing inconsistencies, flight rule violations, data volume issues, and by assisting in Deep Space Network (DSN) coverage analysis. In preparation for extended mission operations, CIMS has also evolved further to assist in the planning and coordination of the dual playback redundancy of highvalue data from targets such as Titan and Enceladus. This paper will outline the critical role that CIMS has played for Cassini in the distributed ops paradigm throughout operations. This paper will also examine the evolution that CIMS has undergone in the face of new science discoveries and fluctuating operational needs. And finally, this paper will conclude with theoretical adaptation of CIMS for other projects and the potential savings in cost and risk reduction that could potentially be tapped into by future missions.

Equils, Douglas J.↗

Medical Data Architecture Prototype Development - Summary of Recent Work and Proposed Ideas for Upcoming Work

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions, and in ExMC Gap Med 10: We do not have the capability to provide computed medical decision support during exploration missions. These gaps recognize the need for a comprehensive medical data management system and the accompanying computational support to provide autonomous medical care during long duration exploration missions. As the MDA matures—including the capability to comprehensively process and discover medically-relevant information to support medical operations during exploration missions—project focus will shift to maturing and extending the MDA platform to enable clinical decision support and real-time guidance. To date, the MDA foundational architecture has recommended exploration medical system Level of Care IV requirements through a series of test bed prototype developments and analog demonstrations. The next stage in the development will focus on more autonomous clinical decision making necessary to address challenges in executing a self-contained medical system that enables health care both with and without assistance from ground support. A thorough understanding of current state of medical decision support systems, advanced machine learning algorithms and vast and varied data sources is required. The development of a clinical decision support for exploration missions (Level of Care V) roadmap is needed: one that assesses of current state of the art of clinical decision support systems (CDSS), interoperability issues, identification of challenges in health and performance monitoring, obtaining and processing information from biosensors, knowledge and data management, data integration and fusion, and advanced algorithm development. This roadmap must also include rapid prototype development in the areas of data processing, advanced analysis and prediction of medical events, and treatment based on medically relevant information processing and evidence-based best practices. In this presentation, an overview of the relevant issues and the beginning framework of a Level of Care V CDSS development roadmap will be provided.

Krihak, M.↗

Crew Health and Performance Integrated Data System Platform Project Updates

Future human exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting crew autonomy for future exploration missions. An integrated data system platform is needed to mitigate these risks by supporting a new generation of technologies and employing advanced analytical and predictive modeling techniques to enable crew autonomy for future exploration missions. The Crew Health and Performance Integrated Data System Platform (CHP-IDSP) project is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. This cohesive integration point will streamline the management of CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.) and facilitate situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the ongoing development effort of the path-to-flight CHP-IDSP software and the demonstration of its core capabilities. This includes a brief history of the project, the human-centered process used to identify data needs and workflows feeding the development of scenarios and requirements, and current subsystem development status. Current integrations, including the Chiron exploration electronic health record application, will be discussed. Future work includes collaboration with additional CHP domains and a flight technology demonstration.

Data integration↗

Crew Health and Performance Integrated Data Service Platform (CHP-IDSP): Project Updates

Future human exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting crew autonomy for future exploration missions. An integrated data services platform is needed to mitigate these risks by supporting a new generation of technologies and employing advanced analytical and predictive modeling techniques to enable crew autonomy for future exploration missions. The Crew Health and Performance Integrated Data System Platform (CHP-IDSP) project is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. This cohesive integration point will streamline the management of CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.) and facilitate situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the ongoing development effort of the path-to-flight CHP-IDSP software and the demonstration of its core capabilities. This includes a brief history of the project, the human-centered process used to identify data needs and workflows feeding the development of scenarios and requirements, and current subsystem development status. Current integrations, including the Chiron exploration electronic health record application, will be discussed. Future work includes collaboration with additional CHP domains and a flight technology demonstration.

Software↗

Application of Risk Assessment Tools in the Continuous Risk Management (CRM) Process

Marshall Space Flight Center (MSFC) of the National Aeronautics and Space Administration (NASA) is currently implementing the Continuous Risk Management (CRM) Program developed by the Carnegie Mellon University and recommended by NASA as the Risk Management (RM) implementation approach. The four most frequently used risk assessment tools in the center are: (a) Failure Modes and Effects Analysis (FMEA), Hazard Analysis (HA), Fault Tree Analysis (FTA), and Probabilistic Risk Analysis (PRA). There are some guidelines for selecting the type of risk assessment tools during the project formulation phase of a project, but there is not enough guidance as to how to apply these tools in the Continuous Risk Management process (CRM). But the ways the safety and risk assessment tools are used make a significant difference in the effectiveness in the risk management function. Decisions regarding, what events are to be included in the analysis, to what level of details should the analysis be continued, make significant difference in the effectiveness of risk management program. Tools of risk analysis also depends on the phase of a project e.g. at the initial phase of a project, when not much data are available on hardware, standard FMEA cannot be applied; instead a functional FMEA may be appropriate. This study attempted to provide some directives to alleviate the difficulty in applying FTA, PRA, and FMEA in the CRM process. Hazard Analysis was not included in the scope of the study due to the short duration of the summer research project.

Paul S. Ray↗

National Aeronautics and Space Administration Marshall Space Flight Center Space Transportation Directorate Risk Management Implementation Program

The US civil aerospace program has been a great contributor to the creation and implementation of techniques and methods to identify, analyze, and confront risk. NASA has accomplished mission success in many instances, but also has had many failures. Anomalies have kept the Agency from achieving success on other occasions, as well. While NASA has mastered ways to prevent risks, and to quickly and effectively react and recover from anomalies or failures, it was not until few years ago that a comprehensive Risk Management process started being implemented in some of its programs and projects. A Continuous Risk Management (CRM) cycle process was developed and has been promoted and used successfully in programs and projects across the Agency.

Duarte, Luis Alberto↗

Lessons Learned in Systems Engineering Availability and Recommendations for Mission Technical Leaders

In spaceflight missions at Goddard Space Flight Center (GSFC), the Mission System Engineer (MSE) is the technical leader of the overall engineering team and also is the Independent Engineering Technical Authority. The responsibility of this role includes the definition of the mission design architecture, concept of operations, and mission requirements, management of risk throughout the development, and verification and validation of the final system performance and function amongst other duties. This responsibility inherently requires time management, enabling focus on a balanced development with appropriate risk. Time is the most valuable resource of the MSE. The system engineer’s availability to interact with the development team (often product or component design leads and technicians, often in different worksites) to discover and mitigate mission risks during development is key to mission success. This paper presents examples from Lunar Reconnaissance Orbiter, Landsat 9, and Neutron star Interior Composition ExploreR (NICER) which represent in-house and out-of-house hardware builds. These examples demonstrate how interactions between the Mission Systems Engineers and other project and partner engineers result in discovery of critical risks, leading to early mitigation with significant cost and performance savings. These three missions would have suffered test failures or on-orbit failures had their MSEs not set aside time to visit engineers and technicians that were working on key pieces of space flight hardware. Availability is more than just time; it is openness to listen to concerns and questions. It begins by building a level of trust in the team that it is safe to ask questions or share concerns without the fear of blame or additional workload. It also requires enabling informal conversations (over lunch, coffee, in the clean room, or at the team members desk, etc.) where key information can be exchanged, and team members may even provide an easy-to-implement mitigation idea for another subsystem. Availability is a highly valuable commodity and completely non-obvious to protect and optimize. The natural tendency of engineers is to keep themselves busy with solving problems that they know about. This paper is encouraging MSEs to resist this tendency to try and solve all the complex problems themselves and actively devote daily time to learning and solving problems that are found with informal communications with other team members.

Lessons Learned↗

Collaborative Systems Engineering in the Ascent Abort-2 Crew Module/Separation Ring Project

Generally speaking, systems engineering (SE) tool-sets face a dilemma balancing power and accessibility. High-powered SE tools (MagicDraw, Cradle, Core, etc.) tend to be specialized and are available only to highly trained Systems Engineers, and/or through the use of a 'back room' developer team making the output products available to the broader team. On the other hand, highly accessible tools (MS Word, Excel, etc.) do not have the power to implement SE in a rigorous manner. NASA has to test all aspects of the new human-rated Orion Multi-Purpose Crew Vehicle spacecraft prior to its first crewed mission. The test program includes uncrewed launch abort flight tests to demonstrate the capability to save the crew in the event that a launch failure occurs. Orion's second abort flight test will be a low-altitude flight test known as "Ascent Abort 2 (AA-2)." This test is currently scheduled to be carried out at Cape Canaveral Air Force Station's Space Launch Complex 46 (SLC-46) in Florida in 2019. NASA's in-house AA-2 Crew Module and Separation Ring (CSR) Team is producing the crew module and separation ring. Operating jointly as both an Advanced Exploration Systems (AES) Project and an Orion Project, the CSR project charter includes development of innovative, streamlined and generally more efficient practices for creation of flight hardware and software. One result of this tasking has been development of a collaborative and data-centric systems engineering environment within the team's shared web environment (Microsoft SharePoint). Through the use of built-in, 'out of the box capabilities' present in MS SharePoint, the CSR Systems Engineering team has created (with some limited developer support) a data-centric architecture for the project's SE implementation, including functional and interface analysis, requirements development and management, risk management, verification planning and management, test results, and end item management. Data elements are linked between data structures so as to define and control relationships between item types, link requirements to parents and children, and link tests to the requirements that they verify. The overall project team integration is increased by also linking SE content to project management content over the project life cycle, including team communication, action items, configuration management, decisional and meeting materials, and life cycle reviews. This presentation will provide an overview of the collaborative SE environment, showing how it provides the power for a number of SE tasks while still providing the accessibility and transparency to allow the full project team to collaborate and succeed. Given the project phase, we'll be able to present a nearly full lifecycle discussion, from concept through verification and approaching delivery.

Systems Engineering environments↗

Managing Risk for Cassini During Mission Operations and Data Analysis (MOandDA)

A Risk Management Process has been tailored for Cassini that not only satisfies the requirements of NASA and JPL, but also allows the Program to proactively identify and assess risks that threaten mission objectives. Cassini Risk Management is a team effort that involves both management and engineering staff. The process is managed and facilitated by the Mission Assurance Manager (MAM), but requires regular interactions with Program Staff and team members to instill the risk management philosophy into the day to day mission operations. While Risk Management is well defined for projects in the development phase, it is a relatively new concept for Mission Operations. The Cassini team has embraced this process and has begun using it in an effective, proactive manner, to ensure mission success. It is hoped that the Cassini Risk Management Process will form the basis by which risk management is conducted during MO&DA on future projects. proactive in identifying, assessing and mitigating risks before they become problems. Cost ehtiveness is achieved by: Comprehensively identifying risks Rapidly assessing which risks require the expenditure of pruject cewums Taking early actions to mitigate these risks Iterating the process frequently, to be responsive to the dynamic internal and external environments The Cassini Program has successfully implemented a Risk Management Process for mission operations, The initial SRL has been developed and input into he online tool. The Risk Management webbased system has been rolled out for use by the flight team and risk owners we working proactive in identifying, assessing and mitigating risks before they become problems. Cost ehtiveness is achieved by: Comprehensively identifying risks Rapidly assessing which risks require the expenditure of pruject cewums Taking early actions to mitigate these risks Iterating the process frequently, to be responsive to the dynamic internal and external environments The Cassini Program has successfully implemented a Risk Management Process for mission operations, The initial SRL has been developed and input into he online tool. The Risk Management webbased system has been rolled out for use by the flight team and risk owners we working put into place will become visible and will be illusmted in future papers.

risk management↗

LISA EDU Status

LISA will be the first space-based gravitational wave observatory, enabling orders of magnitude greater sensitivity than the state-of-the-art LIGO facility. L3Harris is developing an engineering development unit (EDU) telescope in support of NASA, ESA and the LISA Consortium. The LISA EDU telescope validates a flight-like telescope design and reduces risks associated with stability, materials, assembly, integration, and testing. Mission requirements are unlike any other and require picometer-level stability across the entire telescope’s beam path, even in the presence of temperature variation and jitter. As a result, an all-glass telescope design was developed. The brittle structure represents a new state of the art for stable telescopes, but also introduces challenges with managing assembly, manufacturability, and survivability. From 2019-2024, the LISA EDU project has increased manufacturing readiness and technology readiness for the optical telescope element.

Brian VanRensselaer↗