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 73 records · Page 4

Ares I-X Roll Control System Development

Project Managers often face challenging technical, schedule and budget issues. This presentation will explore how the Ares I-X Roll Control System Integrated Product Team (IPT) mitigated challenges such as concurrent engineering requirements and environments and evolving program processes, while successfully managing an aggressive project schedule and tight budget. IPT challenges also included communications and negotiations among inter- and intra-government agencies, including the US Air Force, NASA/MSFC Propulsion Engineering, LaRC, GRC, KSC, WSTF, and the Constellation Program. In order to successfully meet these challenges it was essential that the IPT define those items that most affected the schedule critical path, define early mitigation strategies to reduce technical, schedule, and budget risks, and maintain the end-product focus of an "unmanned test flight" context for the flight hardware. The makeup of the IPT and how it would function were also important considerations. The IPT consisted of NASA/MSFC (project management, engineering, and safety/quality) and contractors (Teledyne Brown Engineering and Pratt and Whitney Rocketdyne, who supplied heritage hardware experience). The early decision to have a small focused IPT working "badgelessly" across functional lines to eliminate functional stove-piping allowed for many more tasks to be done by fewer people. It also enhanced a sense of ownership of the products, while still being able to revert back to traditional roles in order to provide the required technical independence in design reviews and verification closures. This presentation will highlight several prominent issues and discuss how they were mitigated and the resulting Lessons Learned that might benefit other projects.

Unger, Ronald J.↗

Usability of Pre-Flight Planning Interfaces for Supplemental Data Service Provider Tools to Support Uncrewed Aircraft System Traffic Management

Small uncrewed aircraft systems (sUASs) operate in low-altitude, uncontrolled airspace – where support services for their operators (UASOs) are not currently provided. NASA’s System-Wide Safety (SWS) project is identifying the potential risks and hazards to sUAS operations to provide, inform, and improve the designs of In-time Aviation Safety Management Systems (IASMS). The IASMS will include a suite of data-driven tools that compile and analyze data collected from aviation systems and environmental sources to predict hazards, and provide information to allow operators to mitigate these risks (Young et al., 2020). These risk and hazard services can be run and displayed to operators on graphical user interfaces (GUIs), as they relate to a vehicle(s)’ route of flight. These interfaces offer both a means to present hazard service output and offer an opportunity to test user understanding of the information, user decision making, and the best ways to present such data to an operator. Based on these future technologies and intended missions, it is important to investigate interface requirements and evaluate how operators might use these tools. Presenting salient and meaningful risk assessment information to operators is necessary to increase situation awareness and ultimately safety. Building on previous research (Feldman et al., 2022), a usability study comparing two GUIs was conducted to explore how individuals interacted with different styles of information displays. A series of pre-flight hazard and risk-assessment tasks were developed to evaluate participant performance using the Supplemental Data Service Provider Consolidated Dashboard and the Human Automation Team Interface System interfaces. Participants were trained to use both GUIs and their performance was analysed across different scenarios involving multiple sUASs. Performance on simple tasks and the System Usability Scale scores were reported by Feldman et al., 2023. Additional analyses and evaluations on more complex tasks (e.g., risk assessment, prioritization), workload and response times are examined in this paper.

sUAV interfaces↗

Usability of Pre-flight Planning Interfaces for Supplemental Data Service Provider Tools to Support Uncrewed Aircraft System Traffic Management

Small uncrewed aircraft systems (sUASs) operate in low-altitude, uncontrolled airspace – where support services for their operators (UASOs) are not currently provided. NASA’s System-Wide Safety (SWS) project is identifying the potential risks and hazards to sUAS operations to provide, inform, and improve the designs of In-time Aviation Safety Management Systems (IASMS). The IASMS will include a suite of data-driven tools that compile and analyze data collected from aviation systems and environmental sources to predict hazards, and provide information to allow operators to mitigate these risks (Young et al., 2020). These risk and hazard services can be run and displayed to operators on graphical user interfaces (GUIs), as they relate to a vehicle(s)’ route of flight. These interfaces offer both a means to present hazard service output and offer an opportunity to test user understanding of the information, user decision making, and the best ways to present such data to an operator. Based on these future technologies and intended missions, it is important to investigate interface requirements and evaluate how operators might use these tools. Presenting salient and meaningful risk assessment information to operators is necessary to increase situation awareness and ultimately safety. Building on previous research (Feldman et al., 2022), a usability study comparing two GUIs was conducted to explore how individuals interacted with different styles of information displays. A series of pre-flight hazard and risk-assessment tasks were developed to evaluate participant performance using the Supplemental Data Service Provider Consolidated Dashboard and the Human Automation Team Interface System interfaces. Participants were trained to use both GUIs and their performance was analysed across different scenarios involving multiple sUASs. Performance on simple tasks and the System Usability Scale scores were reported by Feldman et al., 2023. Additional analyses and evaluations on more complex tasks (e.g., risk assessment, prioritization), workload and response times are examined in this paper.

sUAV interfaces↗

Recommendation of a More Effective Alternative to the NASA Launch Services Program Mission Integration Reporting System (MIRS) and Implementation of Updates to the Mission Plan

Over the course of my internship in the Flight Projects Office of NASA's Launch Services Program (LSP), I worked on two major projects, both of which dealt with updating current systems to make them more accurate and to allow them to operate more efficiently. The first project dealt with the Mission Integration Reporting System (MIRS), a web-accessible database application used to manage and provide mission status reporting for the LSP portfolio of awarded missions. MIRS had not gone through any major updates since its implementation in 2005, and it was my job to formulate a recommendation for the improvement of the system. The second project I worked on dealt with the Mission Plan, a document that contains an overview of the general life cycle that is followed by every LSP mission. My job on this project was to update the information currently in the mission plan and to add certain features in order to increase the accuracy and thoroughness of the document. The outcomes of these projects have implications in the orderly and efficient operation of the Flight Projects Office, and the process of Mission Management in the Launch Services Program as a whole.

recommendation↗

The X-43 Fin Actuation System Problem - Reliability in Shades of Gray

Following the loss of the first X-43 during launch, the mishap investigation board indicated the Fin Actuator System (FAS) needed to have a larger torque margin. To supply this added torque, a second actuator was added. The consequences of what seemed to be a simple modification would trouble the X-43 program. Because of the second actuator, a new computer board was required. This proved to be subject to electronic noise. This resulted in the actuator latch up in ground tests of the FAS for the second launch. Such a latch up would cause the Pegasus booster to fail, as the FAS was a single string system. The problem was corrected and the second flight was successful. The same modifications were added to the FAS for flight three. When the FAS underwent ground tests, it also latched up. The failure indicated that each computer board had a different tolerance to electronic noise. The problem with the FAS was corrected. Subsequently, another failure occurred, raising questions about the design, and the probability of failure for the X-43 Mach 10 flight. This was not simply a technical issue, but illuminated the difficulties facing both managers and engineers in assessing risk, design requirements, and probabilities in cutting edge aerospace projects.

Peebles, Curtis↗

Initiating the 2002 Mars Science Laboratory (MSL) Focused Technology Program

The Mars Science Laboratory (MSL) Project is an aggressive mission launching in 2009 to deliver a new generation of rover safely to the surface of Mars and conduct comprehensive in situ investigations using a new generation of instruments. This system will be designed to land with precision and be capable of operating over a large percentage on the surface of Mars. It will have capabilities that will support NASA's scientific goals into the next decade of exphation. The MSL Technology program is developing a wide-range of technologies needed for this Mission and potentially other space missions. The MSL Technology Program reports to both the MSL Project and the Mars Technology Program (MTP). The dual reporting process creates a challenging management situation, but ensures the new technology meets both the specific MSL requirements and the broader Mars Program requirements. MTP is a NASA-wide technology development program managed by the Jet Propulsion Laboratory (JPL) and is divided into a Focused Program and a Base Program. The Focused Technology Program addresses technologies that are specific and critical to near-term missions, while the Base Technology Program addresses those technologies that are applicable to multiple missions and which can be characterized as longer term, higher risk, and high payoff technologies. The MSL Technology Program is under the Focused Program and is tightly coupled to MSL's mission milestones and deliverables. The technology budget is separate from the flight Project budget, but the technology s requirements and the development process are tightly coordinated with the Project. The Technology Program combines proven management techniques of flight projects with commercial and academic technology management strategies, to create a technology management program that meets the near-term requirements of MSL and the long-term requirements of MTP. This paper examines the initiation of 2002 MSL Technology program. Some of the areas discussed in this paper include technology definition, task selection, technology management, and technology assessment.

Caffrey, Robert T.↗

Risk Management Implementation Tool

Continuous Risk Management (CM) is a software engineering practice with processes, methods, and tools for managing risk in a project. It provides a controlled environment for practical decision making, in order to assess continually what could go wrong, determine which risk are important to deal with, implement strategies to deal with those risk and assure the measure effectiveness of the implemented strategies. Continuous Risk Management provides many training workshops and courses to teach the staff how to implement risk management to their various experiments and projects. The steps of the CRM process are identification, analysis, planning, tracking, and control. These steps and the various methods and tools that go along with them, identification, and dealing with risk is clear-cut. The office that I worked in was the Risk Management Office (RMO). The RMO at NASA works hard to uphold NASA s mission of exploration and advancement of scientific knowledge and technology by defining and reducing program risk. The RMO is one of the divisions that fall under the Safety and Assurance Directorate (SAAD). I worked under Cynthia Calhoun, Flight Software Systems Engineer. My task was to develop a help screen for the Continuous Risk Management Implementation Tool (RMIT). The Risk Management Implementation Tool will be used by many NASA managers to identify, analyze, track, control, and communicate risks in their programs and projects. The RMIT will provide a means for NASA to continuously assess risks. The goals and purposes for this tool is to provide a simple means to manage risks, be used by program and project managers throughout NASA for managing risk, and to take an aggressive approach to advertise and advocate the use of RMIT at each NASA center.

Wright, Shayla L.↗

Assessment of Medical Risks and Optimization of their Management using Integrated Medical Model

The Integrated Medical Model (IMM) Project is a software-based technique that will identify and quantify the medical needs and health risks of exploration crew members during space flight and evaluate the effectiveness of potential mitigation strategies. The IMM Project employs an evidence-based approach that will quantify probability and consequences of defined in-flight medical risks, mitigation strategies, and tactics to optimize crew member health. Using stochastic techniques, the IMM will ultimately inform decision makers at both programmatic and institutional levels and will enable objective assessment of crew health and optimization of mission success using data from relevant cohort populations and from the astronaut population. The objectives of the project include: 1) identification and documentation of conditions that may occur during exploration missions (Baseline Medical Conditions List [BMCL), 2) assessment of the likelihood of conditions in the BMCL occurring during exploration missions (incidence rate), 3) determination of the risk associated with these conditions and quantify in terms of end states (Loss of Crew, Loss of Mission, Evacuation), 4) optimization of in-flight hardware mass, volume, power, bandwidth and cost for a given level of risk or uncertainty, and .. validation of the methodologies used.

Fitts, Mary A.↗

Human Factors in Training

Future space missions will be significantly longer than current Shuttle missions and new systems will be more complex than current systems. Increasing communication delays between crews and Earth-based support means that astronauts need to be prepared to handle the unexpected on their own. As crews become more autonomous, their potential span of control and required expertise must grow to match their autonomy. It is not possible to train for every eventuality ahead of time on the ground, or to maintain trained skills across long intervals of disuse. To adequately prepare NASA personnel for these challenges, new training approaches, methodologies, and tools are required. This research project aims at developing these training capabilities. Training efforts in FY07 strongly focused on crew medical training, but also began exploring how Space Flight Resource Management training for Mission Operations Directorate (MOD) Flight Controllers could be integrated with systems training for optimal Mission Control Center operations. Beginning in January 2008, the training research effort will include team training prototypes and tools. The Training Task addresses Program risks that lie at the intersection of the following three risks identified by the Project: 1) Risk associated with poor task design; 2) Risk of error due to inadequate information; 3) Risk associated with reduced safety and efficiency due to poor human factors design.

Barshi, Immanuel↗

iPAS: AES Flight System Technology Maturation for Human Spaceflight

In order to realize the vision of expanding human presence in space, NASA will develop new technologies that can enable future crewed spacecraft to go far beyond Earth orbit. These technologies must be matured to the point that future project managers can accept the risk of incorporating them safely and effectively within integrated spacecraft systems, to satisfy very challenging mission requirements. The technologies must also be applied and managed within an operational context that includes both on-board crew and mission support on Earth. The Advanced Exploration Systems (AES) Program is one part of the NASA strategy to identify and develop key capabilities for human spaceflight, and mature them for future use. To support this initiative, the Integrated Power Avionics and Software (iPAS) environment has been developed that allows engineers, crew, and flight operators to mature promising technologies into applicable capabilities, and to assess the value of these capabilities within a space mission context. This paper describes the development of the integration environment to support technology maturation and risk reduction, and offers examples of technology and mission demonstrations executed to date.

Othon, William L.↗

Imaging X-Ray Polarimetry Explorer (IXPE) Risk Management

The Imaging X-ray Polarimetry Explorer (IXPE) project is an international collaboration to build and fly a polarization sensitive X-ray observatory. The IXPE Observatory consists of the spacecraft and payload. The payload is composed of three X-ray telescopes, each consisting of a mirror module optical assembly and a polarization-sensitive X-ray detector assembly; a deployable boom maintains the focal length between the optical assemblies and the detectors. The goal of the IXPE Mission is to provide new information about the origins of cosmic X-rays and their interactions with matter and gravity as they travel through space. IXPE will do this by exploiting its unique capability to measure the polarization of X-rays emitted by cosmic sources. The collaboration for IXPE involves national and international partners during design, fabrication, assembly, integration, test, and operations. The full collaboration includes NASA Marshall Space Flight Center (MSFC), Ball Aerospace, the Italian Space Agency (ASI), the Italian Institute of Astrophysics and Space Planetology (IAPS)/Italian National Institute of Astrophysics (INAF), the Italian National Institute for Nuclear Physics (INFN), the University of Colorado (CU) Laboratory for Atmospheric and Space Physics (LASP), Stanford University, McGill University, and the Massachusetts Institute of Technology. The goal of this paper is to discuss risk management as it applies to the IXPE project. The full IXPE Team participates in risk management providing both unique challenges and advantages for project risk management. Risk management is being employed in all phases of the IXPE Project, but is particularly important during planning and initial execution-the current phase of the IXPE Project. The discussion will address IXPE risk strategies and responsibilities, along with the IXPE management process which includes risk identification, risk assessment, risk response, and risk monitoring, control, and reporting.

IXPE↗

Ares Launch Vehicles Lean Practices Case Study

The Ares launch vehicles team, managed by the Ares Projects Office (APO) at NASA Marshall Space Flight Center, has completed the Ares I Crew Launch Vehicle System Requirements Review and System Definition Review and early design work for the Ares V Cargo Launch Vehicle. This paper provides examples of how Lean Manufacturing, Kaizen events, and Six Sigma practices are helping APO deliver a new space transportation capability on time and within budget, while still meeting stringent technical requirements. For example, Lean philosophies have been applied to numerous process definition efforts and existing process improvement activities, including the Ares I-X test flight Certificate of Flight Readiness (CoFR) process, risk management process, and review board organization and processes. Ares executives learned Lean practices firsthand, making the team "smart buyers" during proposal reviews and instilling the team with a sense of what is meant by "value-added" activities. Since the goal of the APO is to field launch vehicles at a reasonable cost and on an ambitious schedule, adopting Lean philosophies and practices will be crucial to the Ares Project's long-term SUCCESS.

Doreswamy, Rajiv↗

Cost Estimation and Control for Flight Systems

Good program management practices, cost analysis, cost estimation, and cost control for aerospace flight systems are interrelated and depend upon each other. The best cost control process cannot overcome poor design or poor systems trades that lead to the wrong approach. The project needs robust Technical, Schedule, Cost, Risk, and Cost Risk practices before it can incorporate adequate Cost Control. Cost analysis both precedes and follows cost estimation -- the two are closely coupled with each other and with Risk analysis. Parametric cost estimating relationships and computerized models are most often used. NASA has learned some valuable lessons in controlling cost problems, and recommends use of a summary Project Manager's checklist as shown here.

Hammond, Walter E.↗

Safety Risk Knowledge Elicitation in Support of Aeronautical R and D Portfolio Management: A Case Study

Aviation is a problem domain characterized by a high level of system complexity and uncertainty. Safety risk analysis in such a domain is especially challenging given the multitude of operations and diverse stakeholders. The Federal Aviation Administration (FAA) projects that by 2025 air traffic will increase by more than 50 percent with 1.1 billion passengers a year and more than 85,000 flights every 24 hours contributing to further delays and congestion in the sky (Circelli, 2011). This increased system complexity necessitates the application of structured safety risk analysis methods to understand and eliminate where possible, reduce, and/or mitigate risk factors. The use of expert judgments for probabilistic safety analysis in such a complex domain is necessary especially when evaluating the projected impact of future technologies, capabilities, and procedures for which current operational data may be scarce. Management of an R&D product portfolio in such a dynamic domain needs a systematic process to elicit these expert judgments, process modeling results, perform sensitivity analyses, and efficiently communicate the modeling results to decision makers. In this paper a case study focusing on the application of an R&D portfolio of aeronautical products intended to mitigate aircraft Loss of Control (LOC) accidents is presented. In particular, the knowledge elicitation process with three subject matter experts who contributed to the safety risk model is emphasized. The application and refinement of a verbal-numerical scale for conditional probability elicitation in a Bayesian Belief Network (BBN) is discussed. The preliminary findings from this initial step of a three-part elicitation are important to project management practitioners as they illustrate the vital contribution of systematic knowledge elicitation in complex domains.

Shih, Ann T.↗

NASA Spacecraft Fault Management Workshop Results

Fault Management is a critical aspect of deep-space missions. For the purposes of this paper, fault management is defined as the ability of a system to detect, isolate, and mitigate events that impact, or have the potential to impact, nominal mission operations. The fault management capabilities are commonly distributed across flight and ground subsystems, impacting hardware, software, and mission operations designs. The National Aeronautics and Space Administration (NASA) Discovery & New Frontiers (D&NF) Program Office at Marshall Space Flight Center (MSFC) recently studied cost overruns and schedule delays for 5 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 4 out of the 5 missions studied had significant overruns due to underestimating the complexity and support requirements for fault management. As a result of this and other recent experiences, the NASA Science Mission Directorate (SMD) Planetary Science Division (PSD) commissioned a workshop to bring together invited participants across government, industry, academia to assess the state of the art in fault management practice and research, identify current and potential issues, and make recommendations for addressing these issues. The workshop was held in New Orleans in April of 2008. The workshop concluded that fault management is not being limited by technology, but rather by a lack of emphasis and discipline in both the engineering and programmatic dimensions. Some of the areas cited in the findings include different, conflicting, and changing institutional goals and risk postures; unclear ownership of end-to-end fault management engineering; inadequate understanding of the impact of mission-level requirements on fault management complexity; and practices, processes, and tools that have not kept pace with the increasing complexity of mission requirements and spacecraft systems. This paper summarizes the findings and recommendations from that workshop, as well as opportunities identified for future investment in tools, processes, and products to facilitate the development of space flight fault management capabilities.

Newhouse, Marilyn↗

Integrated Circuit Chip Improves Network Efficiency

Prior to 1999 and the development of SpaceWire, a standard for high-speed links for computer networks managed by the European Space Agency (ESA), there was no high-speed communications protocol for flight electronics. Onboard computers, processing units, and other electronics had to be designed for individual projects and then redesigned for subsequent projects, which increased development periods, costs, and risks. After adopting the SpaceWire protocol in 2000, NASA implemented the standard on the Swift mission, a gamma ray burst-alert telescope launched in November 2004. Scientists and developers on the James Webb Space Telescope further developed the network version of SpaceWire. In essence, SpaceWire enables more science missions at a lower cost, because it provides a standard interface between flight electronics components; new systems need not be custom built to accommodate individual missions, so electronics can be reused. New protocols are helping to standardize higher layers of computer communication. Goddard Space Flight Center improved on the ESA-developed SpaceWire by enabling standard protocols, which included defining quality of service and supporting plug-and-play capabilities. Goddard upgraded SpaceWire to make the routers more efficient and reliable, with features including redundant cables, simultaneous discrete broadcast pulses, prevention of network blockage, and improved verification. Redundant cables simplify management because the user does not need to worry about which connection is available, and simultaneous broadcast signals allow multiple users to broadcast low-latency side-band signal pulses across the network using the same resources for data communication. Additional features have been added to the SpaceWire switch to prevent network blockage so that more robust networks can be designed. Goddard s verification environment for the link-and-switch implementation continuously randomizes and tests different parts, constantly anticipating situations, which helps improve communications reliability. It has been tested in many different implementations for compatibility.

Source record↗

Multi-Party Flight Trajectory Negotiation for Upper Class E Traffic Management

A new operational concept has been proposed in Upper Class E airspace at or above 60,000 feet (Flight Level / FL600), which will allow operators of diverse vehicle characteristics to cooperatively manage and share their operational intents with neighboring operators to avoid conflict. There is a consensus in the community that negotiation for strategic deconfliction is needed, but there are no specific guidelines for how the negotiation should be conducted. There is a need for a structured and cooperative way to resolve the conflict between a wide variety of aircraft projected to be operating in Upper Class E for the negotiation to be carried out routinely. The use of negotiation models are a promising solution that can resolve conflict risks during flight in real-time while taking into account the uncertainty of future vehicle positions and dynamic business considerations. A two-party negotiation model has been researched, but as the traffic demand grows, there is a higher likelihood of conflict involving multiple aircraft that would require a method to handle multi-party conflict. This paper proposes a cooperative multi-party negotiation model inspired by game theory concepts for application to flight trajectory negotiation in Upper Class E traffic management. This model can be applied in flight with operators communicating directly after a potential conflict is detected. Some of the model’s benefits include allowing business costs to be private to operators, allowing operators to collaborate together to find conflict-free flight trajectories, and being compatible with different aircraft and operation types. This model provides a structured procedure for conflict resolution that can handle conflict involving multiple parties, assuming each operator is willing to take on a small cost to themselves in order to reduce the total cost to the group.

Upper Class E Traffic Management (ETM)↗

Advancing the practice of systems engineering at JPL

In FY 2004, JPL launched an initiative to improve the way it practices systems engineering. The Lab's senior management formed the Systems Engineering Advancement (SEA) Project in order to "significantly advance the practice and organizational capabilities of systems engineering at JPL on flight projects and ground support tasks." The scope of the SEA Project includes the systems engineering work performed in all three dimensions of a program, project, or task: 1. the full life-cycle, i.e., concept through end of operations 2. the full depth, i.e., Program, Project, System, Subsystem, Element (SE Levels 1 to 5) 3. the full technical scope, e.g., the flight, ground and launch systems, avionics, power, propulsion, telecommunications, thermal, etc. The initial focus of their efforts defined the following basic systems engineering functions at JPL: systems architecture, requirements management, interface definition, technical resource management, system design and analysis, system verification and validation, risk management, technical peer reviews, design process management and systems engineering task management, They also developed a list of highly valued personal behaviors of systems engineers, and are working to inculcate those behaviors into members of their systems engineering community. The SEA Project is developing products, services, and training to support managers and practitioners throughout the entire system lifecycle. As these are developed, each one needs to be systematically deployed. Hence, the SEA Project developed a deployment process that includes four aspects: infrastructure and operations, communication and outreach, education and training, and consulting support. In addition, the SEA Project has taken a proactive approach to organizational change management and customer relationship management - both concepts and approaches not usually invoked in an engineering environment. This paper'3 describes JPL's approach to advancing the practice of systems engineering at the Lab. It describes the general approach used and how they addressed the three key aspects of change: people, process and technology. It highlights a list of highly valued personal behaviors of systems engineers, discusses the various products, services and training that were developed, describes the deployment approach used, and concludes with several lessons learned.

process improvement↗