Engineering Papers⌕ Search

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.

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

At least 523 records · Page 29
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

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

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

Lessons Learned↗
NASA NTRSDate not supplied

ISS Lessons Learned, Looking ahead to Artemis

A review of some lessons from integrated testing for the International Space Station and applying those lessons toward aspects of the Artemis campaign.

International Space Station↗
NASA NTRS2005

Lessons learned from the NEPTUNE power system and other deep-sea adventures

The development of underwater science systems presents some challenging technical issues. It seems that the best efforts of the engineers and scientists involved are sometimes inadequate, and projects that once seemed straightforward end up being late, or overbudget, or cancelled. This paper will review some of the lessons that may be learned from the examples of three science projects in the deep ocean: the DUMAND neutrino detector, the H20 observatory, and the power system part of the NEPTUNE regional cabled observatory.

ocean science↗
NASA NTRS1993

Profile of NASA software engineering: Lessons learned from building the baseline

It is critically important in any improvement activity to first understand the organization's current status, strengths, and weaknesses and, only after that understanding is achieved, examine and implement promising improvements. This fundamental rule is certainly true for an organization seeking to further its software viability and effectiveness. This paper addresses the role of the organizational process baseline in a software improvement effort and the lessons we learned assembling such an understanding for NASA overall and for the NASA Goddard Space Flight Center in particular. We discuss important, core data that must be captured and contrast that with our experience in actually finding such information. Our baselining efforts have evolved into a set of data gathering, analysis, and crosschecking techniques and information presentation formats that may prove useful to others seeking to establish similar baselines for their organization.

Hall, Dana↗
NASA NTRS1997

Lessons learned studying design issues for lunar and Mars settlements

In a study of lunar and Mars settlement concepts, an analysis was made of fundamental design assumptions in five technical areas against a model list of occupational and environmental health concerns. The technical areas included the proposed science projects to be supported, habitat and construction issues, closed ecosystem issues, the "MMM" issues (mining, material processing, and manufacturing), and the human elements of physiology, behavior, and mission approach. Four major lessons were learned. First it is possible to relate public health concerns to complex technological development in a proactive design mode, which has the potential for long-term cost savings. Second, it became very apparent that prior to committing any nation or international group to spending the billions to start and complete a lunar settlement, over the next century, that a significantly different approach must be taken from those previously proposed, to solve the closed ecosystem and "MMM" problems. Third, it also appears that the health concerns and technology issues to be addressed for human exploration into space are fundamentally those to be solved for human habitation of the Earth (as a closed ecosystem) in the 21st century. Finally, it is proposed that ecosystem design modeling must develop new tools, based on probabilistic models as a step up from closed circuit models.

Life Support Systems↗
NASA NTRS2001

Challenges and lessons learned in the application of autonomy to space operations

NASA's Space Operations Management Office (SOMO) is working toward a goal of providing an integrated infrastructure of mission and data services for space missions undertaken by NASA enterprises. A significant portion of this effort is focused on reducing the cost of these services. We are interested in the potential of autonomy to reduce operations costs. Some attempts have already been made to apply autonomy and automation in these areas in the past with varying degrees of success. We present brief case histories and the lessons inferred from them. Combining this past experience with anticipated future needs, we attempt to clarify the challenges that must be met in order to realize the benefits of autonomy.

challenges↗
NASA NTRS2012

CloudSat Anomaly Recovery and Operational Lessons Learned

Nov 2011: NASA/JPL declared CloudSat fully operational in DO ]OP Mode . CloudSat collects science data during sunlit portion of orbit, stable spin hibernation in eclipse . New CONOPS requires constant monitoring of thermal and power profiles, while allowing collection of 54 mins of science data per sunlit orbit

spacecraft systems↗
NASA NTRS2005

Learning Lessons from the X-37 Project

The X-37 was planned as an automated vehicle capable of flight-testing new aerospace technologies in combined environments that are beyond the capability of existing ground or flight platforms. Flight demonstration with the X-37 architecture and configuration in relevant environments was planned to reduce the risk of developing launch vehicle technologies for sustainable, affordable exploration and other aerospace applications. Current plans are for the X-37 Approach and Landing Test Vehicle (ALTV) to be atmospheric tested in 2005 from Scaled Composite's White Knight carrier aircraft at up to 40,000 feet over California's Mojave Spaceport, with and turnaround maintenance performed. The fight Operations Control Center will conduct the mission, using a streamlined operations concept. Taxi-tow and captive-carry tests will be conducted prior to the atmospheric-test series. Sponsored by the Defense Advanced Research Projects Agency (DARPA) with NASA participation, technical objectives are to: (1) mature Computed Air Data System/Remote Pressure Sensor technology, (2) manage energy during Terminal Area Energy Management/Heading Alignment Cone maneuvers, and (3) validate the aerodatabase. The X-37 Project began in 1999 under a cooperative agreement as an element of NASA's Future X Program and transitioned to a NASA Research Announcement under the Space Launch Initiative. In mid-2004, NASA transferred ownership to DARPA, with its heritage of performing high-risk, high-payoff research and development. NASA contributes technical expertise, including risk analysis and system integration. The Boeing Company is the prime contractor, with nationwide suppliers. This recent partnership exemplifies the synergy attainable when NASA Centers, other Government agencies, and industry work together toward a common goal - contributing to the knowledge base for U.S. exploration and other aerospace endeavors. The X-37 team represents a range of space transportation disciplines - from engineering to management. Some members have been with the project since its inception. All have gained priceless experience during the design, manufacturing, and testing of the ALTV, as well as through developing advanced orbital flight technologies, such as state-of-the-art Thermal Protection Systems and hot structures. Throughout this process, the X-37 Project team captures lessons that are directly applicable to other such efforts. The upcoming ALTV flights offer another dimension of data and first-hand experience that will prove invaluable to those designing new generations of reusable spacecraft. And ongoing technology developments will expand the aerospace knowledge base. Delivering prototype hardware is always a risky proposition. During the course of the X-37 effort, the team has experienced many challenging opportunities, delivering significant accomplishments and learning numerous lessons in the process. The ability to manage the risk landscape is key to overcoming obstacles, especially technical hurdles that are encountered in progressing hardware from design to flight. The approach to managing risk under this partnership is evolving but, in general, the team allocates resources to reduce the likelihood of severe-consequence risks, thus maximizing mission success and ensuring that the X-37 Project delivers value to its stakeholders. As the team sharpens its focus on operations, it continues to contribute knowledge to those who would undertake high-risk, high-payoff research and development and provides valuable experience to implement the exploration vision.

Turner, Susan↗
NASA NTRS2005

Learning Lessons from the X-37 Project

The X-37 was planned as an automated vehicle capable of flight-testing new aerospace technologies in combined environments that are beyond the capability of existing ground or flight platforms. Flight demonstration with the X-37 architecture and configuration in relevant environments was planned to reduce the risk of developing launch vehicle technologies for sustainable, affordable exploration and other aerospace applications. Current plans are for the X-37 Approach and Landing Test Vehicle (ALTV) to be atmospheric tested in 2005 from Scaled Composite s White Knight carrier aircraft at up to 40,000 feet over California's Mojave Spaceport, with landing and turnaround maintenance performed. The Flight Operations Control Center will conduct the mission, using a streamlined operations concept. Taxi-tow and captive-carry tests will be conducted prior to the atmospheric-test series. Sponsored by the Defense Advanced Research Projects Agency (DARPA) with NASA participation, technical objectives are to: (1) mature Computed Air Data System/Remote Pressure Sensor technology, (2) manage energy during Terminal Area Energy Management/Heading Alignment Cone maneuvers, and (3) validate the aerodatabase. The X-37 Project began in 1999 under a cooperative agreement as an element of NASA's Future X Program and transitioned to a NASA Research Announcement under the Space Launch Initiative. In mid-2004, NASA transferred ownership to DARPA, with its heritage of performing high-risk, high-payoff research and development (R&D). NASA contributes technical expertise, including risk analysis and system integration. The Boeing Company is the prime contractor, with nationwide suppliers. This partnership exemplifies the synergy attainable when NASA Centers, other Government agencies, and industry work together toward a common goal - contributing to the knowledge base for U.S. exploration and other aerospace endeavors. The X-37 team represents a range of space transportation disciplines - from engineering to management. Some members have been with the project since its inception. All have gained priceless experience during the design, manufacturing, and testing of the ALTV, as well as through developing advanced orbital flight technologies, such as state-of-the-art Thermal Protection Systems and hot structures. Throughout this process, the X-37 Project team captures lessons that are directly applicable to other such efforts. The upcoming ALTV flights offer another dimension of data and first-hand experience that will prove invaluable to those designing new generations of reusable spacecraft. And ongoing technology developments will expand the aerospace knowledge base. Delivering prototype hardware is always a risky proposition. During the course of this effort, the X-37 team has experienced many challenging opportunities, delivering significant accomplishments and learning numerous lessons in the process. The ability to manage the risk landscape is key to overcoming obstacles, especially technical hurdles that are encountered in progressing hardware from design to flight. The approach to managing risk under this partnership is evolving but, in general, the team allocates resources to reduce the likelihood of severe-consequence risks, thus maximizing mission success and ensuring that the X-37 Project delivers value to its stakeholders. As the team sharpens its focus on operations, it continues to contribute knowledge to those who would undertake high-risk, high-payoff R&D and provides valuable experience to implement the Vision for Space Exploration.

Turner, Susan↗