Results for “risk management flight projects” — Page 6

NASA NTRS2018

Medical Data Architecture (MDA) Project Status

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. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.

medical data architecture↗

NASA NTRS2019

Medical Data Architecture (MDA) Project Status

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. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗

NASA NTRS2024

Integrated Systems Engineering, Safety, Reliability and Risk Management – Minimizing Black Swan Events

This paper examines key barriers that can possibly inhibit safe and reliable mission execution and, in the worst case, result in loss of human life due to many unknown contributory factors that can lead to Black Swan events. Some of the representative contributory factors include decision errors, overconfidence and a host of common causes including cultural and human factors. Decisions are always easy to criticize in hindsight when more information is available after a major accident. Depending on the type and complexity of the project and/or mission, the catastrophic risks of drifting into failure can be alleviated by implementing uniquely and strategically tailored Integrated-System-of-Systems, dynamic, risk-informed decision management processes. This paper presents some of the lessons learned from James Webb Space Telescope (JWST), NASA’s Human Space Flight program, and industry that provide motivation to organizations working on mega-complex missions to prudently accomplish targeted mission success. These lessons are important for future human Lunar, Mars and Beyond missions planned to be pursued by NASA through a public-private partnership using nimble but effective safety-conscious, proven sound engineering practices including implementation of integrated risk mitigation practices.

SLS↗

NASA NTRS2010

Heritage and Advanced Technology Systems Engineering Lessons Learned from NASA Space Missions

Use of heritage and new technology is necessary/enabling to implementing small, low cost missions, yet overruns decrease the ability to sustain future mission flight rates The majority of the cost growth drivers seen in the D&NF study were embedded early during formulation phase and later realized during the development and I&T phases Cost drivers can be avoided or significantly decreased by project management and SE emphasis on early identification of risks and realistic analyses SE processes that emphasize an assessment of technology within the mission system to identify technical issues in the design or operational use of the technology. Realistic assessment of new and heritage spacecraft technology assumptions , identification of risks and mitigation strategies. Realistic estimates of effort required to inherit existing or qualify new technology, identification of risks to estimates and develop mitigation strategies. Allocation of project reserves for risk-based mitigation strategies of each individual area of heritage or new technology. Careful tailoring of inheritance processes to ensure due diligence.

Barley, Bryan↗

NASA NTRS1994

Increases in efficiency and enhancements to the Mars Observer non-stored commanding process

The Mars Observer team was, until the untimely loss of the spacecraft on August 21, 1993, performing flight operations with greater efficiency and speed than any previous JPL mission of its size. This level of through-put was made possible by a mission operations system which was composed of skilled personnel using sophisticated sequencing and commanding tools. During cruise flight operations, however, it was realized by the project that this commanding level was not going to be sufficient to support the activities planned for mapping operations. The project had committed to providing the science instrument principle investigators with a much higher level of commanding during mapping. Thus, the project began taking steps to enhance the capabilities of the flight team. One mechanism used by project management was a tool available from total quality management (TQM). This tool is known as a process action team (PAT). The Mars Observer PAT was tasked to increase the capacity of the flight team's nonstored commanding process by fifty percent with no increase in staffing and a minimal increase in risk. The outcome of this effort was, in fact, to increase the capacity by a factor of 2.5 rather than the desired fifty percent and actually reduce risk. The majority of these improvements came from the automation of the existing command process. These results required very few changes to the existing mission operations system. Rather, the PAT was able to take advantage of automation capabilities inherent in the existing system and make changes to the existing flight team procedures.

Brooks, Robert N., Jr.↗

NASA NTRS2016

Successful Completion of the JWST OGSE2 Cryogenic Test at JSC Chamber-A While Managing Numerous Challenges

The James Webb Space Telescope (JWST) Optical Telescope Element (OTE) assembly is the largest optically stable infrared-optimized telescope currently being manufactured and assembled, and scheduled for launch in 2018. The JWST OTE, including the primary mirrors, secondary mirror, and the Aft Optics Subsystems (AOS) are designed to be passively cooled and operate at near 45 degrees Kelvin. Due to the size of its large sunshield in relation to existing test facilities, JWST cannot be optically or thermally tested as a complete observatory-level system at flight temperatures. As a result, the telescope portion along with its instrument complement will be tested as a single unit very late in the program, and on the program schedule critical path. To mitigate schedule risks, a set of 'pathfinder' cryogenic tests will be performed to reduce program risks by demonstrating the optical testing capabilities of the facility, characterizing telescope thermal performance, and allowing project personnel to learn valuable testing lessons off-line. This paper describes the 'pathfinder' cryogenic test program, focusing on the recently completed second test in the series called the Optical Ground Support Equipment 2 (OGSE2) test. The JWST OGSE2 was successfully completed within the allocated project schedule while faced with numerous conflicting thermal requirements during cool-down to the final cryogenic operational temperatures, and during warm-up after the cryo-stable optical tests. The challenges include developing a pre-test cool-down and warm-up profiles without a reliable method to predict the thermal behaviors in a rarified helium environment, and managing the test article hardware safety driven by the project Limits and Constraints (L&C's). Furthermore, OGSE2 test included the time critical Aft Optics Subsystem (AOS), a part of the flight Optical Telescope Element that would need to be placed back in the overall telescope assembly integrations. The OGSE2 test requirements included the strict adherence of the project contamination controls due to the presence of the contamination sensitive flight optical elements. The test operations required close coordination of numerous personnel while they being exposed and trained for the 'final' combined OTE and instrument cryo-test in 2017. This paper will also encompass the OGSE2 thermal data look-back review.

JWST OGSE2 Cryogenic Test↗

NASA NTRS2022

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↗

NASA NTRS2022

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↗

NASA NTRS2011

Fission Power System Technology for NASA Exploration Missions

Under the NASA Exploration Technology Development Program, and in partnership with the Department of Energy (DOE), NASA is conducting a project to mature Fission Power System (FPS) technology. A primary project goal is to develop viable system options to support future NASA mission needs for nuclear power. The main FPS project objectives are as follows: 1) Develop FPS concepts that meet expected NASA mission power requirements at reasonable cost with added benefits over other options. 2) Establish a hardware-based technical foundation for FPS design concepts and reduce overall development risk. 3) Reduce the cost uncertainties for FPS and establish greater credibility for flight system cost estimates. 4) Generate the key products to allow NASA decisionmakers to consider FPS as a preferred option for flight development. In order to achieve these goals, the FPS project has two main thrusts: concept definition and risk reduction. Under concept definition, NASA and DOE are performing trade studies, defining requirements, developing analytical tools, and formulating system concepts. A typical FPS consists of the reactor, shield, power conversion, heat rejection, and power management and distribution (PMAD). Studies are performed to identify the desired design parameters for each subsystem that allow the system to meet the requirements with reasonable cost and development risk. Risk reduction provides the means to evaluate technologies in a laboratory test environment. Non-nuclear hardware prototypes are built and tested to verify performance expectations, gain operating experience, and resolve design uncertainties.

Mason, Lee↗

NASA NTRS2012

The Advanced Exploration Systems Water Recovery Project: Innovation on 2 Fronts

As NASA looks forward to sending humans farther away from Earth, we will have to develop a transportation architecture that is highly reliable and that can sustain life for long durations without the benefit of Earth s proximity for continuous resupply or even operational guidance. NASA has consistently been challenged with performing great feats of innovation, but particularly in this time of economic stress, we are challenged to go farther with less. The Advanced Exploration Systems (AES) projects were implemented to address both of these needs by not only developing innovative technologies, but by incorporating innovative management styles and processes that foster the needed technical innovation given a small amount of resources. This presentation explains how the AES Water Recovery Project is exhibiting innovation on both fronts; technical and process. The AES Water Recovery Project (WRP) is actively engineering innovative technologies in order to maximize the efficiency of water recovery. The development of reliable, energy-efficient, and low-mass spacecraft systems to provide environmental control and life support (ECLS) is critical to enable long-duration human missions outside of low-Earth orbit. Recycling of life support consumables is necessary to reduce resupply mass and provide for vehicle autonomy. To address this, the WRP is working on a rotary distiller that has shown enhanced performance over the state-of-the-art (SOA). Additionally, the WRP is looking at innovative ways to address issues present in the state-of-the-art (SOA) systems pertaining to toxicity and calcium scale buildup. As an AES project, the WRP has a more streamlined Skunk Works like approach to technology development intended to reduce overhead but achieve a more refined end product. The project has incorporated key partnerships between NASA centers as well as between NASA and industry. A minimal project management style has been implemented such that risks are managed and milestones tracked without overburdening the team with reporting demands that take them away from their work. A lean Systems Engineering (SE) approach has been implemented where project objectives are defined and vetted early without overprescribing the process or limiting the ability to innovate. Finally, we are working with existing flight hardware support organizations like operations, safety, materials and others to impact the system design at the breadboard level. This type of early input is a key to ensuring that the technologies are developed on the right track to becoming space flight worthy.

Sarguisingh, Miriam M.↗

NASA NTRSDate not supplied

Aggregate Risk Tool for Human Space Flight

This project utilized Data fusion capabilities developed from the 2020-2022 Information Fusion (IFDA) IRAD to enhance functionality of a Human Spaceflight (HSF) Aggregate Risk Product developed by the JSC Flight Safety Office. The tool compiles and presents risk data from multiple Program and Commercial Provider vehicles to provide a holistic assessment of residual risk to Program Managers and Technical Authorities prior to HSF Launches. The aggregation or coupling of risks from multiple sources (Examples: PRA, variances, anomaly data bases, Program Risk Management data bases, technical review board minutes, Hazard Analysis, etc.) when analyzed, identify potential areas of elevated risk in components, systems or mission phases that would otherwise be undetected by nonintegrated program risk management tools and possesses.

Patrick Huckaby↗

NASA NTRS2007

The X-43A Flight Research Program: Lessons Learned on the Road to Mach 10

During an aerospace engineer's undergraduate studies, he or she will attend classes in aerodynamics, thermodynamics, structures, stability and control, dynamics, design, propulsion, and computer science, along with the related courses in mathematics, physics, statistics, and chemistry required to understand the material. Upon graduation, the new engineer will have acquired a basic knowledge of how to build an aerospace vehicle. What only comes through experience, however, is the understanding of the inevitable imperfect process through which an aerospace vehicle is built. This is the adventure of turning a basic concept into functional hardware. Engineers working on a project must often deal with ambiguous situations. They are routinely asked by management to provide risk assessments of a project, yet even after careful analysis uncertainties remain. The project must be accomplished within finite limits of time and money. The question an engineer answers is whether the solution to potential problem is worth the cost and schedule delay, or if the solution might actually be worse than the problem it is meant to solve. Review protocols are established to ensure that an unknown has not been overlooked. But these cannot protect against an unknown unknown. Examples of these situations can be found in the history of the X-43A Hyper-X (Hypersonic Experiment) program. In this NASA project, a supersonic combustion ramjet (scramjet) engine was flight tested on a subscale vehicle. The X-43A Hyper-X Research Vehicle (HXRV) was launched from a B-52B mothership, then boosted to the test speed by a modified Pegasus rocket first stage, called the Hyper-X Launch Vehicle (HXLV). Once at the proper speed and altitude, the X-43A separated from the booster, stabilized itself, and then the engine test began. Although wind-tunnel scramjet engine tests had begun in the late 1950s, before the Hyper-X program there had never been an actual in-flight test of such an engine integrated with an appropriate airframe. Thus, while the scramjet had successfully operated in the artificial airflow of wind tunnels, the concept had yet to be proven in real air. These conditions meant changes in density and temperature, as well as changes in angle of attack and sideslip of a free-flying vehicle. A wind tunnel is limited in its ability to simulate these subtle factures, which have a major impact on almost any vehicle, but especially that of a scramjet's performance. The Hyper-X project was to provide a real-world benchmark of the ground test data. The full scale X-43A engine would be operated in the wind tunnel, and then flown, and the data from its operation would then be compared with projections. If these matched, the wind tunnel data would be considered a reliable design tool for future scramjet. If there were significant differences, the reasons for these would have to be identified. Until such information was available, scramjets would lack the technological maturity to be considered for future space launch or high-speed atmospheric flight vehicles.

Peebles, Curtis↗

NASA NTRS2008

DARPA/USAF/USN J-UCAS X-45A System Demonstration Program: A Review of Flight Test Site Processes and Personnel

The Joint Unmanned Combat Air Systems (J-UCAS) program is a collaborative effort between the Defense Advanced Research Project Agency (DARPA), the US Air Force (USAF) and the US Navy (USN). Together they have reviewed X-45A flight test site processes and personnel as part of a system demonstration program for the UCAV-ATD Flight Test Program. The goal was to provide a disciplined controlled process for system integration and testing and demonstration flight tests. NASA's Dryden Flight Research Center (DFRC) acted as the project manager during this effort and was tasked with the responsibilities of range and ground safety, the provision of flight test support and infrastructure and the monitoring of technical and engineering tasks. DFRC also contributed their engineering knowledge through their contributions in the areas of autonomous ground taxi control development, structural dynamics testing and analysis and the provision of other flight test support including telemetry data, tracking radars, and communications and control support equipment. The Air Force Flight Test Center acted at the Deputy Project Manager in this effort and was responsible for the provision of system safety support and airfield management and air traffic control services, among other supporting roles. The T-33 served as a J-UCAS surrogate aircraft and demonstrated flight characteristics similar to that of the the X-45A. The surrogate served as a significant risk reduction resource providing mission planning verification, range safety mission assessment and team training, among other contributions.

Cosentino, Gary B.↗

NASA NTRSDate not supplied

A Technology Maturation Plan for the Development of Nuclear Electric Propulsion

Over the last two years NASA’s Space Nuclear Propulsion (SNP) Project formulated a Technology Maturation Plan (TMP) for development of the sub-systems needed for a MW-class Nuclear Electric Propulsion (NEP) system which, combined with a high thrust chemical propulsion stage, would be suitable for human missions to Mars. Two recent assessments, independently conducted by the National Academies for Science, Engineering, and Medicine and the NASA Engineering & Safety Center, concluded that the technologies required for a high-power NEP system are immature and the attendant risks insufficiently quantified to justify initiating a flight project. For NEP to be available as a viable option to meet flight opportunities in the late 2030s / 2040s time frame, development of the key sub-systems must begin now. SNP has subdivided the NEP system into five Critical Technology Elements (CTE): the nuclear reactor, power conversion, power management and distribution, electric propulsion sub-system, and the primary heat rejection system. Development plans for each of these CTEs have been drafted which will serve as the template for a focused milestone-driven research and development campaign intended to advance each CTE to Technology Readiness Level (TRL) 5. This will be accomplished by building and testing hardware at relevant power levels (~ 1 MW) and for relevant durations (2,500 hours, ~10% of the required operational lifetime) and conducting numerical modeling of the CTEs anchored by the accumulated test data to predict system performance and reliability. Concurrent with this work, high-level coupled system/mission modeling will be carried out to refine the key performance parameters that the various CTEs must achieve. Non-advocate reviews will be held at milestone points to assess progress and inform down-select decisions. The strategy for formulating the TMP was described previously; this paper describes ongoing progress on the drafting and baselining of the plan, including key specific details.

Space Nuclear Propulsion↗

NASA NTRSDate not supplied

A Technology Maturation Plan for the Development of Nuclear Electric Propulsion

Over the last two years NASA’s Space Nuclear Propulsion (SNP) Project formulated a Technology Maturation Plan (TMP) for development of the sub-systems needed for a MW-class Nuclear Electric Propulsion (NEP) system which, combined with a high thrust chemical propulsion stage, would be suitable for human missions to Mars. Two recent assessments, independently conducted by the National Academies for Science, Engineering, and Medicine and the NASA Engineering & Safety Center, concluded that the technologies required for a high-power NEP system are immature and the attendant risks insufficiently quantified to justify initiating a flight project. For NEP to be available as a viable option to meet flight opportunities in the late 2030s / 2040s time frame, development of the key sub-systems must begin now. SNP has subdivided the NEP system into five Critical Technology Elements (CTE): the nuclear reactor, power conversion, power management and distribution, electric propulsion sub-system, and the primary heat rejection system. Development plans for each of these CTEs have been drafted which will serve as the template for a focused milestone-driven research and development campaign intended to advance each CTE to Technology Readiness Level (TRL) 5. This will be accomplished by building and testing hardware at relevant power levels (~ 1 MW) and for relevant durations (2,500 hours, ~10% of the required operational lifetime) and conducting numerical modeling of the CTEs anchored by the accumulated test data to predict system performance and reliability. Concurrent with this work, high-level coupled system/mission modeling will be carried out to refine the key performance parameters that the various CTEs must achieve. Non-advocate reviews will be held at milestone points to assess progress and inform down-select decisions. The strategy for formulating the TMP was described previously*; this paper describes ongoing progress on the drafting and baselining of the plan, including key specific details. * “Strategy for Developing Technologies for Megawatt-class Nuclear Electric Propulsion Systems”, K.A. Polzin, et. al., International Electric Propulsion Conference IEPC 2022, IEPC-2022-155

Nuclear Electric Propulsion↗

NASA NTRS2020

History and Logic Model NASA Goddard Space Flight Center Instrument and Payload Systems Engineering Technical Performance Study

Historically, some NASA missions have exceeded schedule and cost commitments. Studies suggest technical performance is a contributor. The 1980 NASA Project Management Study concluded, "one of the most significant contributors to cost and schedule growth is inadequate definition of technical and management aspects of a program..." (as cited in GAO/NSIAD-93-97, p. 11). The 1991 NASA Roles and Missions Report identified a "need for increased emphasis on technological readiness and requirements on the front end of a program" (as cited in GAO/NSIAD-93-97, p. 11). The 1992 NASA Program Costs Report stated that NASA officials identified, among other things, "insufficient definition studies... [and] program redesigns and technical complexities" as reasons for cost and schedule overruns (GAO/NSAID-93-97, p. 11). The 2002 Task Force on Acquisition of National Security Space Programs found "requirements definition and control issues, unhealthy cost bias in proposal evaluation, widespread lack of budget reserves required to implement high risk programs on schedule, and an overall underappreciation of the importance of appropriately staffed and trained system engineering staff to manage the technologically demanding and unique aspects of space programs" (DoD, 2003, p.i.) In 2007, The NASA Office of the Chief Engineer chartered the NASA Instrument Capability Study (NICS) “to determine whether NASA instrument developers are facing challenges that impact the capability to design and build quality instruments or whether there are flaws in the acquisition strategy evidenced by schedule delays, cost overruns, and increased technical risk via design deficiencies. The... team was also chartered to determine if occurrences [are]... isolated cases or if there are generic issues... If the issues [are] found to be generic, the team [is] to offer solutions to recover such capability" (NICS Report, 2008, p. vi). The 2008 NICS Report, led by Goddard Space Flight Center (GSFC), identified challenges to instrument technical performance consistent with findings from previous reports. In 2017, the Instrument Project Division (IPD) Implementation Study was initiated to determine if there was a change in meeting schedule and cost commitments after implementing certain NICS recommendations. In 2018, the Instrument Technical Performance Study was initiated to determine the current state of Instrument Technical Performance in the GSFC Payload & Instrument Systems Engineering Branch. The purpose of the combined studies is to answer the question, "Is there a relationship between meeting NASA scientific instrument technical success and meeting schedule and cost commitments? If yes, what is the relationship?" References Department of Defense Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics. (2003). The report of the defense science board/ air force scientific advisory board joint task force on acquisition of national security space programs. Washington DC. Government Accounting Office. (1992). NASA program costs: Space missions require substantially more funding than initially estimated. GAO/NSIAD-93-97. Washington DC. National Aeronautics and Space Administration, National Oceanic and Atmospheric Agency, Department of Defense. (2008). The NASA instrument capability study final report. NP-2008-11-058-GSFC. Washington DC.

Robbins, Geraldine↗

NASA NTRSDate not supplied

The Ejectable Data Recorder: A Lean, Risk-Informed Approach for Hardware Development

NASA is developing the Orion spacecraft to transport crew from the Earth to the Moon as part of the Artemis series of missions. To provide a crew escape capability from pre-launch through ascent, the Orion vehicle is equipped with a Launch Abort System (LAS), built by Lockheed Martin, which pulls the capsule away from the launch vehicle in the event of an abort scenario. The Ascent Abort 2 (AA-2) test flight occurred on July 2, 2019,and tested a production version of the LAS to ensure that it can operate as intended, and to collect a large data set from hundreds of sensors on the vehicle to support Orion flight certification. In the original AA-2 architecture, a single-string set of communications antennas on the LAS would downlink all of the in-flight test data to ground stations. However, that communications architecture was predicted to have data dropouts during abort and jettison of the LAS, and would not support data transmission at all after LAS jettison. As a result, a comprehensive trade study was completed, yielding the addition of antennas on the crew module (CM), a buffer/rebroadcast capability for key portions of the flight, and an ejectable data recorder (EDR) subsystem. This EDR subsystem would serve as a backup to the radio frequency (RF) communications system, and would be non-flight critical, providing a unique capability that enabled management to take a different approach with the hardware and software development. The Crew Module and Separation Ring were developed as “Class 1”Flight Hardware, albeit with some tailoring approaches to enable efficiencies. The Class 1 designation requires full rigor for flight hardware and software, documenting everything that happens to a piece of hardware from procurement through disposal, requiring a full spectrum of acceptance tests, and the highest rigor of quality assurance processes. At the other end of the spectrum, Class 3hardware is controlled, but not intended for flight, and leaves the level of rigor up to the project manager. This classification is often used for research and development projects. Similarly,Class-1E has been recently defined at NASA for ISS payloads and technology development projects that are not flight critical and do not need the full rigor of Class 1 to be successful. The EDR subsystem was challenged at commencement to adopt a skunkworks and agile-like approach to hardware development, allowing for a different risk posture than the rest of the AA-2 hardware. After initially pursuing Class 1 processes, the EDR subsystem design evolved to incorporating numerous commercial components, leading to re-designation as a Class-1E subsystem. The resulting EDR subsystem was fully successful in meeting all flight system requirements, and achieved 100% retrieval of flight test data. This paper will discuss the risk posture of the EDR subsystem and the subsequent tailoring that was enacted as part of its Class-1E status.

EDR↗

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗