SEARCH · Engineering Papers

Results for “Lessons learned”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

At least 1,045 records · Page 58

All sources NASA NTRS DOE OSTI

NASA NTRS2014

Lessons We Learned Designing and Building the Chandra Telescope

2014 marks the crystal (15th) anniversary of the launch of the Chandra X‐ray Observatory. This paper offers some of the major lessons learned by some of the key members of the Chandra Telescope team. We offer some of the lessons gleaned from our experiences developing, designing, building and testing the telescope and its subsystems, with 15 years of hindsight. Among the topics to be discussed are the early developmental tests, known as VETA‐I and VETA‐II, requirements derivation, the impact of late requirements and reflection on the conservatism in the design process.

Arenberg, Jonathan↗

NASA NTRS2015

Lessons from 30 Years of Flight Software

This presentation takes a brief historical look at flight software over the past 30 years, extracts lessons learned and shows how many of the lessons learned are embodied in the Flight Software product line called the core Flight System (cFS). It also captures the lessons learned from developing and applying the cFS.

Flight Software↗

NASA NTRS2011

Surviving the Lead Reliability Engineer Role in High Unit Value Projects

A project with a very high unit value within a company is defined as a project where a) the project constitutes one of a kind (or two-of-a-kind) national asset type of project, b) very large cost, and c) a mission failure would be a very public event that will hurt the company's image. The Lead Reliability engineer in a high visibility project is by default involved in all phases of the project, from conceptual design to manufacture and testing. This paper explores a series of lessons learned, over a period of ten years of practical industrial experience by a Lead Reliability Engineer. We expand on the concepts outlined by these lessons learned via examples. The lessons learned are applicable to all industries.

lessons learned↗

NASA NTRS2004

Ontology Development and Evolution in the Accident Investigation Domain

InvestiigationOrganizer (IO) is a collaborative semantic web system designed to support the conduct of mishap investigations. IO provides a common repository for a wide range of mishap related information, allowing investigators to integrate evidence, causal models, and investigation results. IO has been used to support investigations ranging from a small property damage case to the loss of the Space Shuttle Columbia. Through IO'S use in these investigations, we have learned significant lessons? about the application of ontologies and semantic systems to solving real-world problems. This paper will describe the development of the ontology within IO, from the initial development, its growth in response to user requests during use in investigations, and the recent work that was done to control the results of that growth. This paper will also describe the lessons learned from this experience and how they may apply to the implementaton of future ontologies and semantic systems.

Carvalho, Robert↗

NASA NTRS2014

Cost Analysis in a Multi-Mission Operations Environment

Spacecraft control centers have evolved from dedicated, single-mission or single mission-type support to multi-mission, service-oriented support for operating a variety of mission types. At the same time, available money for projects is shrinking and competition for new missions is increasing. These factors drive the need for an accurate and flexible model to support estimating service costs for new or extended missions; the cost model in turn drives the need for an accurate and efficient approach to service cost analysis. The National Aeronautics and Space Administration (NASA) Huntsville Operations Support Center (HOSC) at Marshall Space Flight Center (MSFC) provides operations services to a variety of customers around the world. HOSC customers range from launch vehicle test flights; to International Space Station (ISS) payloads; to small, short duration missions; and has included long duration flagship missions. The HOSC recently completed a detailed analysis of service costs as part of the development of a complete service cost model. The cost analysis process required the team to address a number of issues. One of the primary issues involves the difficulty of reverse engineering individual mission costs in a highly efficient multi-mission environment, along with a related issue of the value of detailed metrics or data to the cost model versus the cost of obtaining accurate data. Another concern is the difficulty of balancing costs between missions of different types and size and extrapolating costs to different mission types. The cost analysis also had to address issues relating to providing shared, cloud-like services in a government environment, and then assigning an uncertainty or risk factor to cost estimates that are based on current technology, but will be executed using future technology. Finally the cost analysis needed to consider how to validate the resulting cost models taking into account the non-homogeneous nature of the available cost data and the decreasing flight rate. This paper presents the issues encountered during the HOSC cost analysis process, and the associated lessons learned. These lessons can be used when planning for a new multi-mission operations center or in the transformation from a dedicated control center to multi-center operations, as an aid in defining processes that support future cost analysis and estimation. The lessons can also be used by mature service-oriented, multi-mission control centers to streamline or refine their cost analysis process.

Felton, Larry↗

NASA NTRS2014

Cost Analysis In A Multi-Mission Operations Environment

Spacecraft control centers have evolved from dedicated, single-mission or single missiontype support to multi-mission, service-oriented support for operating a variety of mission types. At the same time, available money for projects is shrinking and competition for new missions is increasing. These factors drive the need for an accurate and flexible model to support estimating service costs for new or extended missions; the cost model in turn drives the need for an accurate and efficient approach to service cost analysis. The National Aeronautics and Space Administration (NASA) Huntsville Operations Support Center (HOSC) at Marshall Space Flight Center (MSFC) provides operations services to a variety of customers around the world. HOSC customers range from launch vehicle test flights; to International Space Station (ISS) payloads; to small, short duration missions; and has included long duration flagship missions. The HOSC recently completed a detailed analysis of service costs as part of the development of a complete service cost model. The cost analysis process required the team to address a number of issues. One of the primary issues involves the difficulty of reverse engineering individual mission costs in a highly efficient multimission environment, along with a related issue of the value of detailed metrics or data to the cost model versus the cost of obtaining accurate data. Another concern is the difficulty of balancing costs between missions of different types and size and extrapolating costs to different mission types. The cost analysis also had to address issues relating to providing shared, cloud-like services in a government environment, and then assigning an uncertainty or risk factor to cost estimates that are based on current technology, but will be executed using future technology. Finally the cost analysis needed to consider how to validate the resulting cost models taking into account the non-homogeneous nature of the available cost data and the decreasing flight rate. This paper presents the issues encountered during the HOSC cost analysis process, and the associated lessons learned. These lessons can be used when planning for a new multi-mission operations center or in the transformation from a dedicated control center to multi-center operations, as an aid in defining processes that support future cost analysis and estimation. The lessons can also be used by mature serviceoriented, multi-mission control centers to streamline or refine their cost analysis process.

Newhouse, M.↗

NASA NTRSDate not supplied

Semantic Search with Sentence-BERT for Design Information Retrieval

Managing and referencing design knowledge is a critical activity in the design process. However, reliably retrieving useful knowledge can be a frustrating experience for users of knowledge management systems due to inherent limitations of standard keyword-based searches. In this research, we consider the task of retrieving relevant lessons learned from the NASA Lessons Learned Information System (LLIS). To this end, we apply a state-of-the-art natural language processing (NLP) technique for information retrieval (IR): semantic search with sentence-BERT, which is a modification of a Bidirectional Encoder Representations from Transformers (BERT) model that uses siamese and triplet network architectures to obtain semantically meaningful sentence embeddings. While the pre-trained sBERT model performs well out-of-the-box, we further fine-tune the model on data from the LLIS so that it learns on design engineering-relevant vocabulary. We quantify the improvement in query results using both standard sBERT and fine-tuned sBERT over a keyword search. Our use case throughout the paper is to use queries related to specific requirements from a NASA project. Fine tuning the sBERT model on LLIS data yields a mean average precision (MAP) of 0.807 on queries based on information needs from a real NASA project. Results indicate that applying state-of-the-art natural language processing techniques, especially when finetuned using engineering data, to design information retrieval tasks shows significant promise in modernizing design knowledge management systems.

Hannah S. Walsh↗

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

Roth, Brian↗

NASA NTRS2024

Flight Mechanics Modeling and Simulation of the Earth Entry System

Introduction: The Mars Sample Return (MSR) Campaign being planned by NASA and ESA has the ambitious goal to return Mars samples back to Earth. This international collaboration had developed a concept of operations that included a ESA-designed Earth Return Orbiter (ERO) and NASA-designed Capture, Containment, and Return System (CCRS). The Earth Entry System (EES), consisting of a protective aeroshell that houses the samples as well as sample containment vessels, would conduct entry, descent, and landing (EDL) on a direct Earth trajectory. The EES would enter on a spin-stabilized ballistic trajectory with the goal to passively achieve aerodynamic stability throughout all regions of flight. The EDL sequence would end with the EES impacting the soft playa soil of the Utah Test and Training Range (UTTR). As of the submission of this abstract, the MSR campaign is undergoing a re-architecture leading to a pause in EES development. However, the novel approaches developed in flight mechanics modeling and simulation can significantly benefit the greater IPPW community in the development of Earth return vehicles. This paper will present the latest state of EES flight mechanics modeling and simulation. The paper will highlight the simulation architecture developed and key lessons learned from understanding of EDL trajectory sensitivities. Modeling and Simulation: Figure 1 provides a high-level concept of operations for the approach, entry, descent, and landing (AEDL) phase of the CCRS-portion of MSR. The objective of EES flight mechanics is to model and simulate the EES trajectory from ERO separation to ground impact at UTTR. A variety of flight mechanics simulation models were utilized to model both exo-atmopsheric and atmospheric portions of flight. 42, a 6-DOF simulation developed at Goddard Space Flight Center, is utilized for propagating the attitude of EES during exo-atmospheric flight. 42 allows for a variety of spin eject mechanism scenarios to be simulated for analysis. 10 minutes prior to entry, the 42 states are handed off to the EDL sims. The prime EDL sim utilized by EES is the Program to Optimize Simulated Trajectories II (POST2), a 6-DOF sim developed at Langley Research Center, and the independent verification and validation EDL sim utilized is DSENDS, a 6-DOF sim developed at Jet Propulsion Laboratory. Figure 2 provides a visualization of the flight mechanics simulation model flow through various points in the AEDL phase. Due to the existence of a variety of sim models, the EES flight mechanics team developed processes for data hand-off. These processes included the development of a centralized coordinate frame document, utilization of a single, centralized simulation input document for all sims to reference, and hand-off files containing both the technical data to be ingested by other flight mechanics sims as well as annotations of modeling assumptions utilized to generate the data. Figure~\ref{fig:post2simarchitecture} provides an overview of the POST2 sim architecture wherein POST2 ingests numerous subsystem models and input files. The dispersed state file generated by MONTE provides the position/velocity state of the trajectory while the 42 Handoff file provides the attitude. The aerodynamics database, delivered by the EES aeroscience team, is utilized to simulate the aerodynamic forces and moments experienced during EDL. A custom atmosphere model, developed by EES atmosphere team, is utilized to simulate the anticipated atmosphere environment around the region of Earth through which the EES trajectory flys. These inputs and subsystem models can be varied depending on the AEDL flight mechanics scenario being simulated. Monte Carlo simulations are utilized to generate statistical AEDL performance metrics in the form of scorecards and violin plots. Furthermore, outputs from the POST2 simulation are utilized for follow-on analyses including aerothermal and landing performance. \section{Flight Mechanics Lessons Learned} Though the EES flight mechanics team uncovered a variety of lessons learned through the analysis conducted to support CCRS through preliminary design review, this paper will highlight the most important lessons. A key AEDL performance goal is to ensure the landing footprint of EES remains on the UTTR south range. A common modeling strategy used in EDL analysis is One-Variable-At-a-Time (OVAT). OVAT analysis provides insight into the key drivers that affect AEDL performance metrics. Figure 3 shows the landing ellipses for single dispersion sources as compared to the baseline aggregate of all dispersions. The figure shows that atmosphere winds alone dominate the size of the footprint ellipse (note: EES does not use a parachute unlike previous Earth-return missions and is in wind-driven free fall for ~5min). The significance of the wind led the EES flight mechanics team to pursue the development of a Custom Atmosphere Model [4], in lieu of EarthGRAM [1], built on actual radiosonde wind measurements around the UTTR-region. This decision was driven by the realism in the generated footprint ellipses and lessons-learned from Stardust [5]. These findings will be invaluable for future Earth-return missions in providing an early understanding of the key drivers affecting footprint size and modeling considerations for which to account. Another lesson learned is tied to the AEDL performance goal of achieving passive stability throughout all regions of flight. It is well understood that blunt-body aeroshells are less stable as they transition from supersonic to subsonic. Eliminating a backshell does help improvestability; however, other phenomena such as roll-induced instability during terminal descent can still arise. The EES flight mechanics team developed stability metrics as tools to better understand the causes of and better predict the onset of dynamic instability. These tools were built upon analytical models developed by Jaffe [3] and Murphy [2]. The tools were shown to both be very accurate in correlation with actual unstable cases and useful in developing stability margin policies based on the vehicle design and simulation considerations (e.g. sphere-cone angle change, mass change, wind turbulence). These tools allowed for the current EES design to demonstrate the ability to achieve passive stability and can be an invaluable tool for consideration in the design of parachute-less Earth-return vehicles.

Rohan Deshmukh↗

NASA NTRS2010

Introduction of the Space Shuttle Columbia Accident, Investigation Details, Findings and Crew Survival Investigation Report

As the Space Shuttle Program comes to an end, it is important that the lessons learned from the Columbia accident be captured and understood by those who will be developing future aerospace programs and supporting current programs. Aeromedical lessons learned from the Accident were presented at AsMA in 2005. This Panel will update that information, closeout the lessons learned, provide additional information on the accident and provide suggestions for the future. To set the stage, an overview of the accident is required. The Space Shuttle Columbia was returning to Earth with a crew of seven astronauts on 1Feb, 2003. It disintegrated along a track extending from California to Louisiana and observers along part of the track filmed the breakup of Columbia. Debris was recovered from Littlefield, Texas to Fort Polk, Louisiana, along a 567 statute mile track; the largest ever recorded debris field. The Columbia Accident Investigation Board (CAIB) concluded its investigation in August 2003, and released their findings in a report published in February 2004. NASA recognized the importance of capturing the lessons learned from the loss of Columbia and her crew and the Space Shuttle Program managers commissioned the Spacecraft Crew Survival Integrated Investigation Team (SCSIIT) to accomplish this. Their task was to perform a comprehensive analysis of the accident, focusing on factors and events affecting crew survival, and to develop recommendations for improving crew survival, including the design features, equipment, training and procedures intended to protect the crew. NASA released the Columbia Crew Survival Investigation Report in December 2008. Key personnel have been assembled to give you an overview of the Space Shuttle Columbia accident, the medical response, the medico-legal issues, the SCSIIT findings and recommendations and future NASA flight surgeon spacecraft accident response training. Educational Objectives: Set the stage for the Panel to address the investigation, medico-legal issues, the Spacecraft Crew Survival Integrated Investigation Team report and training for accident response.

Chandler, Michael↗

NASA NTRS2011

The Habitat Demonstration Unit Project: A Modular Instrumentation System for a Deep Space Habitat

NASA is focused on developing human exploration capabilities in low Earth orbit (LEO), expanding to near Earth asteroids (NEA), and finally to Mars. Habitation is a crucial aspect of human exploration, and a current focus of NASA activities. The Habitation Demonstration Unit (HDU) is a project focused on developing an autonomous habitation system that enables human exploration of space by providing engineers and scientists with a test bed to develop, integrate, test, and evaluate habitation systems. A critical feature of the HDU is the instrumentation system, which monitors key subsystems within the habitat. The following paper will discuss the HDU instrumentation system performance and lessons learned during the 2010 Desert Research and Technology Studies (D-RaTS). In addition, this paper will discuss the evolution of the instrumentation system to support the 2011 Deep Space Habitat configuration, the challenges, and the lessons learned of implementing this configuration. In 2010, the HDU was implemented as a pressurized excursion module (PEM) and was tested at NASA s D-RaTS in Arizona [1]. For this initial configuration, the instrumentation system design used features that were successful in previous habitat instrumentation projects, while also considering challenges, and implementing lessons learned [2]. The main feature of the PEM instrumentation system was the use of a standards-based wireless sensor node (WSN), implementing an IEEE 802.15.4 protocol. Many of the instruments were connected to several WSNs, which wirelessly transmitted data to the command and data handling system via a mesh network. The PEM instrumentation system monitored the HDU during field tests at D-RaTS, and the WSN data was later analyzed to understand the performance of this system. In addition, several lessons learned were gained from the field test experience, which fed into the instrumentation design of the next generation of the HDU.

Rojdev, Kristina↗

NASA NTRS1995

The Clementine mechanisms

The Clementine spacecraft was developed under the 'faster, better, cheaper' theme. The constraints of a low budget coupled with an unusually tight schedule forced many departures from the normal spacecraft development methods. This paper discusses technical lessons learned about several of the mechanisms on the Clementine spacecraft as well as managerial lessons learned for the entire mechanisms subsystem. A quick overview of the Clementine mission is included; the mission schedule and environment during the mechanisms releases and deployment are highlighted. This paper then describes the entire mechanisms subsystem. The design and test approach and key philosophies for a fast-track program are discussed during the description of the mechanisms subsystem. The mechanism subsystem included a marman clamp separation system, a separation nut separation system, a solar panel deployment and pointing system, a high gain antenna feed deployment system, and two separate sensor cover systems. Each mechanism is briefly discussed. Additional technical discussion is given on the marman clamp design, the sensor cover designs, and the design and testing practices for systems driven by heated actuators (specifically paraffin actuators and frangibolts). All of the other mechanisms were of conventional designs and will receive less emphasis. Lessons learned are discussed throughout the paper as they applied to the systems being discussed. Since there is information on many different systems, this paper is organized so that information on a particular topic can be quickly referenced.

Purdy, William↗

NASA NTRS2011

The Right Stuff: A Look Back at Three Decades of Flight Controller Training for Space Shuttle Mission Operations

Operations of human spaceflight systems is extremely complex, therefore the training and certification of operations personnel is a critical piece of ensuring mission success. Mission Control Center (MCC-H), at the Lyndon B. Johnson Space Center, in Houston, Texas manages mission operations for the Space Shuttle Program, including the training and certification of the astronauts and flight control teams. This paper will give an overview of a flight control team s makeup and responsibilities during a flight, and details on how those teams are trained and certified. The training methodology for developing flight controllers has evolved significantly over the last thirty years, while the core goals and competencies have remained the same. In addition, the facilities and tools used in the control center have evolved. These changes have been driven by many factors including lessons learned, technology, shuttle accidents, shifts in risk posture, and generational differences. Flight controllers will share their experiences in training and operating the Space Shuttle throughout the Program s history. A primary method used for training Space Shuttle flight control teams is by running mission simulations of the orbit, ascent, and entry phases, to truly "train like you fly." The reader will learn what it is like to perform a simulation as a shuttle flight controller. Finally, the paper will reflect on the lessons learned in training for the shuttle program, and how those could be applied to future human spaceflight endeavors. These endeavors could range from going to the moon or to Mars. The lessons learned from operating the space shuttle for over thirty years will help the space industry build the next human transport space vehicle and inspire the next generation of space explorers.

Dittemore, Gary D.↗

NASA NTRS1994

Re-engineering the Multimission Command System at the Jet Propulsion Laboratory

The Operations Engineering Lab (OEL) at JPL has developed the multimission command system as part of JPL's Advanced Multimission Operations System. The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The command functions include real-time command generation, command translation and radiation, status reporting, some remote control of Deep Space Network antenna functions, and command file management. The mission-independent architecture has allowed easy adaptation to new flight projects and the system currently supports all JPL planetary missions (Voyager, Galileo, Magellan, Ulysses, Mars Pathfinder, and CASSINI). This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. The redesign has allowed streamlining of command operations with significant improvements in productivity and ease of use. In addition, the new system has provided a command capability that works equally well for real-time operations and within a spacecraft testbed. This paper will also discuss new development work including a multimission command database toolkit, a universal command translator for sequencing and real-time commands, and incorporation of telecommand capabilities for new missions.

Alexander, Scott↗

NASA NTRS2006

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

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), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), 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 an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; 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.

systems engineering↗

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)↗

NASA NTRS2011

Ares Knowledge Capture: Summary and Key Themes Presentation

This report has been developed by the National Aeronautics and Space Administration (NASA) Human Exploration and Operations Mission Directorate (HEOMD) Risk Management team in close coordination with the MSFC Chief Engineers Office. This document provides a point-in-time, cumulative, summary of actionable key lessons learned derived from the design project. Lessons learned invariably address challenges and risks and the way in which these areas have been addressed. Accordingly the risk management thread is woven throughout the document.

Ares Knowledge↗