Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “scope”

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 235 records · Page 13

A Wind-powered Rover for a Low-Cost Venus Mission

Venus, with a surface temperature of 450 C and an atmospheric pressure 90 times higher than that of the Earth, is a difficult target for exploration. However, high-temperature electronics and power systems now being developed make it possible that future missions may be able to operate in the Venus environment. Powering such a rover within the scope of a Discovery class mission will be difficult, but harnessing Venus' surface winds provides a possible way to keep a powered rover small and light. This project scopes out the feasibility of a wind-powered rover for Venus surface missions. Two rover concepts, a land-sailing rover and a wind-turbine-powered rover, were considered. The turbine-powered rover design is selected as being a low-risk and low-cost strategy. Turbine detailed analysis and design shows that the turbine can meet mission requirements across the desired range of wind speeds by utilizing three constant voltage generators at fixed gear ratios.

Benigno, Gina↗

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

U.S. Spacesuit Knowledge Capture Series Catalog

The National Aeronautics and Space Administration (NASA) and other organizations have been performing U.S. Spacesuit Knowledge Capture (USSKC) since the beginning of space exploration through published reports, conference presentations, specialized seminars, and classes instructed by veterans in the field. The close physical interaction between spacesuit systems and human beings makes them among the most personally evocative pieces of space hardware. Consequently, spacesuit systems have required nearly constant engineering refinements to do their jobs without impinging on human activity. Since 2008, spacesuit knowledge capture has occurred through video recording, engaging both current and former specialists presenting technical scope specifically to educate individuals and preserve knowledge. These archives of spacesuit legacy reflect its rich history and will provide knowledge that will enhance the chances for the success of future and more ambitious spacesuit system programs. The scope and topics of USSKC have included lessons learned in spacesuit technology; experience from the Gemini, Apollo, Skylab, and Shuttle Programs; the process of hardware certification, design, development, and other program components; spacesuit evolution and experience; failure analysis and resolution; and aspects of program management. USSKC activities have progressed to a level where NASA, the National Air and Space Museum (NASM), Hamilton Sundstrand (HS) and the spacesuit community are now working together to provide a comprehensive way to organize and archive intra-agency information related to the development of spacesuit systems. These video recordings are currently being reviewed for public release using NASA export control processes. After a decision is made for either public or non-public release (internal NASA only), the videos and presentations will be available through the NASA Johnson Space Center Engineering Directorate (EA) Engineering Academy, the NASA Technical Reports Server (NTRS), the NASA Aeronautics & Space Database (NA&SD), or NASA YouTube. Event availability is duly noted in this catalog.

Bitterly, Rose↗

Consolidated Development Objectives Document (CDOD) For MB-60

This document defines the objectives related to liquid rocket engine system development to be undertaken by JAXA in support of the Space Launch System (SLS) Program managed out of the NASA Marshall Space Flight Center (MSFC). These objectives include furnishing the necessary management, labor, facilities, tools, equipment, and materials required to execute the specified activities. 1.1 Project Scope: The scope of this effort is to develop a rocket engine and associated products per the objectives and technical requirements established in this document. This engine, minus the engine controller, designated here as MB ]60, is to be developed through to a prequalification point of maturity. It is assumed that should JCNE ]1 development proceed beyond this maturity point towards actual flight qualification, the engine controller will be supplied and integrated by NASA. 1.2 Document Structure: The structure of this Consolidated Development Objectives Document (CDOD) includes a traditional description of objectives in a SOO, plus the associated Data Products Document (DPD) in an attached appendix, and then Engine Requirements Document (ERD) as another attached appendix. It is the intent that this document, in conjunction with the cited applicable documents, should constitute a complete programmatic and technical description of the development effort to be pursued.

Greene, William D.↗

Athena in 2013 and Beyond

TRISA, the U.S. Army TRADOC G2 Intelligence Support Activity, received Athena 1 in 2009. They first used Athena 3 to support studies in 2011. This paper describes Athena 4, which they started using in October 2012. A final section discusses issues that are being considered for incorporation into Athena 5 and later. Athena's objective is to help skilled intelligence analysts anticipate the likely consequences of complex courses of action that use our country's entire power base, not just our military capabilities, for operations in troubled regions of the world. Measures of effectiveness emphasize who is in control and the effects of our actions on the attitudes and well-being of civilians. The planning horizon encompasses not weeks or months, but years. Athena is a scalable, laptop-based simulation with weekly resolution. Up to three months of simulated time can pass between game turns that require user interaction. Athena's geographic scope is nominally a country, but can be a region within a county. Geographic resolution is "neighborhoods", which are defined by the user and may be actual neighborhoods, provinces, or anything in between. Models encompass phenomena whose effects are expected to be relevant over a medium-term planning horizon-three months to three years. The scope and intrinsic complexity of the problem dictate a spiral development process. That is, the model is used during development and lessons learned are used to improve the model. Even more important is that while every version must consider the "big picture" at some level of detail, development priority is given to those issues that are most relevant to currently anticipated studies. For example, models of the delivery and effectiveness of information operations messaging were among the additions in Athena 4.

Chamberlain, Robert G.↗

Advanced Strategic and Tactical Relay Request Management for the Mars Relay Operations Service

This software provides a new set of capabilities for the Mars Relay Operations Service (MaROS) in support of Strategic and Tactical relay, including a highly interactive relay request Web user interface, mission control over relay planning time periods, and mission management of allowed strategic vs. tactical request parameters. Together, these new capabilities expand the scope of the system to include all elements critical for Tactical relay operations. Planning of replay activities spans a time period that is split into two distinct phases. The first phase is called Strategic, which begins at the time that relay opportunities are identified, and concludes at the point that the orbiter generates the flight sequences for on board execution. Any relay request changes from this point on are called Tactical. Tactical requests, otherwise called Orbit - er Relay State Changes (ORSC), are highly restricted in terms of what types of changes can be made, and the types of parameters that can be changed may differ from one orbiter to the next. For example, one orbiter may be able to delay the start of a relay request, while another may not. The legacy approach to ORSC management involves exchanges of e-mail with "requests for change" and "acknowledgement of approval," with no other tracking of changes outside of e-mail folders. MaROS Phases 1 and 2 provided the infrastructure for strategic relay for all supported missions. This new version, 3.0, introduces several capabilities that fully expand the scope of the system to include tactical relay. One new feature allows orbiter users to manage and "lock" Planning Periods, which allows the orbiter team to formalize the changeover from Strategic to Tactical operations. Another major feature allows users to interactively submit tactical request changes via a Web user interface. A third new feature allows orbiter missions to specify allowed tactical updates, which are automatically incorporated into the tactical change process. This software update is significant in that it provides the only centralized service for tactical request management available for relay missions.

Allard, Daniel A.↗

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗

Rewriting Modulo SMT

Combining symbolic techniques such as: (i) SMT solving, (ii) rewriting modulo theories, and (iii) model checking can enable the analysis of infinite-state systems outside the scope of each such technique. This paper proposes rewriting modulo SMT as a new technique combining the powers of (i)-(iii) and ideally suited to model and analyze infinite-state open systems; that is, systems that interact with a non-deterministic environment. Such systems exhibit both internal non-determinism due to the system, and external non-determinism due to the environment. They are not amenable to finite-state model checking analysis because they typically are infinite-state. By being reducible to standard rewriting using reflective techniques, rewriting modulo SMT can both naturally model and analyze open systems without requiring any changes to rewriting-based reachability analysis techniques for closed systems. This is illustrated by the analysis of a real-time system beyond the scope of timed automata methods.

Rocha, Camilo↗

Configuration Management Process Assessment Strategy

Purpose: To propose a strategy for assessing the development and effectiveness of configuration management systems within Programs, Projects, and Design Activities performed by technical organizations and their supporting development contractors. Scope: Various entities CM Systems will be assessed dependent on Project Scope (DDT&E), Support Services and Acquisition Agreements. Approach: Model based structured against assessing organizations CM requirements including best practices maturity criteria. The model is tailored to the entity being assessed dependent on their CM system. The assessment approach provides objective feedback to Engineering and Project Management of the observed CM system maturity state versus the ideal state of the configuration management processes and outcomes(system). center dot Identifies strengths and risks versus audit gotcha's (findings/observations). center dot Used "recursively and iteratively" throughout program lifecycle at select points of need. (Typical assessments timing is Post PDR/Post CDR) center dot Ideal state criteria and maturity targets are reviewed with the assessed entity prior to an assessment (Tailoring) and is dependent on the assessed phase of the CM system. center dot Supports exit success criteria for Preliminary and Critical Design Reviews. center dot Gives a comprehensive CM system assessment which ultimately supports configuration verification activities.*

Henry, Thad↗

Initial Assessment of a Variable-Camber Continuous Trailing-Edge Flap System on a Rigid Wing for Drag Reduction in Subsonic Cruise

In this paper, we describe an initial optimization study of a Variable-Camber Continuous Trailing-Edge Flap (VCCTEF) system. The VCCTEF provides a light-weight control system for aircraft with long flexible wings, providing efficient high-lift capability for takeoff and landing, and greater efficiency with reduced drag at cruising flight by considering the effects of aeroelastic wing deformations in the control law. The VCCTEF system is comprised of a large number of distributed and individually-actuatable control surfaces that are constrained in movement relative to neighboring surfaces, and are non-trivially coupled through structural aeroelastic dynamics. Minimzation of drag results in a constrained, coupled, non-linear optimization over a high-dimension search space. In this paper, we describe the modeling, analysis, and optimization of the VCCTEF system control inputs for minimum drag in cruise. The purpose of this initial study is to quantify the expected benefits of the system concept. The scope of this analysis is limited to consideration of a rigid wing without structural flexibility in a steady-state cruise condition at various fuel weights. For analysis, we developed an optimization engine that couples geometric synthesis with vortex-lattice analysis to automate the optimization procedure. In this paper, we present and describe the VCCTEF system concept, optimization approach and tools, run-time performance, and results of the optimization at 20%, 50%, and 80% fuel load. This initial limited-scope study finds the VCCTEF system can potentially gain nearly 10% reduction in cruise drag, provides greater drag savings at lower operating weight, and efficiency is negatively impacted by the severity of relative constraints between control surfaces.

trailing edge flaps↗

Coupled Solid Rocket Motor Ballistics and Trajectory Modeling for Higher Fidelity Launch Vehicle Design

Multi-stage launch vehicles with solid rocket motors (SRMs) face design optimization challenges, especially when the mission scope changes frequently. Significant performance benefits can be realized if the solid rocket motors are optimized to the changing requirements. While SRMs represent a fixed performance at launch, rapid design iterations enable flexibility at design time, yielding significant performance gains. The streamlining and integration of SRM design and analysis can be achieved with improved analysis tools. While powerful and versatile, the Solid Performance Program (SPP) is not conducive to rapid design iteration. Performing a design iteration with SPP and a trajectory solver is a labor intensive process. To enable a better workflow, SPP, the Program to Optimize Simulated Trajectories (POST), and the interfaces between them have been improved and automated, and a graphical user interface (GUI) has been developed. The GUI enables real-time visual feedback of grain and nozzle design inputs, enforces parameter dependencies, removes redundancies, and simplifies manipulation of SPP and POST's numerous options. Automating the analysis also simplifies batch analyses and trade studies. Finally, the GUI provides post-processing, visualization, and comparison of results. Wrapping legacy high-fidelity analysis codes with modern software provides the improved interface necessary to enable rapid coupled SRM ballistics and vehicle trajectory analysis. Low cost trade studies demonstrate the sensitivities of flight performance metrics to propulsion characteristics. Incorporating high fidelity analysis from SPP into vehicle design reduces performance margins and improves reliability. By flying an SRM designed with the same assumptions as the rest of the vehicle, accurate comparisons can be made between competing architectures. In summary, this flexible workflow is a critical component to designing a versatile launch vehicle model that can accommodate a volatile mission scope.

Ables, Brett↗

Reflections on Centaur Upper Stage Integration by the NASA Lewis (Glenn) Research Center

The NASA Glenn (then Lewis) Research Center (GRC) led several expendable launch vehicle (ELV) projects from 1963 to 1998, most notably the Centaur upper stage. These major, comprehensive projects included system management, system development, integration (both payload and stage), and launch operations. The integration role that GRC pioneered was truly unique and highly successful. Its philosophy, scope, and content were not just invaluable to the missions and vehicles it supported, but also had significant Agencywide benefits. An overview of the NASA Lewis Research Center (now the NASA Glenn Research Center) philosophy on ELV integration is provided, focusing on Atlas/Centaur, Titan/Centaur, and Shuttle/Centaur vehicles and programs. The necessity of having a stable, highly technically competent in-house staff is discussed. Significant depth of technical penetration of contractor work is another critical component. Functioning as a cohesive team was more than a concept: GRC senior management, NASA Headquarters, contractors, payload users, and all staff worked together. The scope, content, and history of launch vehicle integration at GRC are broadly discussed. Payload integration is compared to stage development integration in terms of engineering and organization. Finally, the transition from buying launch vehicles to buying launch services is discussed, and thoughts on future possibilities of employing the successful GRC experience in integrating ELV systems like Centaur are explored.

Launch Vehicle↗

Ontological Modeling for Integrated Spacecraft Analysis

Current spacecraft work as a cooperative group of a number of subsystems. Each of these requiresmodeling software for development, testing, and prediction. It is the goal of my team to create anoverarching software architecture called the Integrated Spacecraft Analysis (ISCA) to aid in deploying the discrete subsystems' models. Such a plan has been attempted in the past, and has failed due to the excessive scope of the project. Our goal in this version of ISCA is to use new resources to reduce the scope of the project, including using ontological models to help link the internal interfaces of subsystems' models with the ISCA architecture.I have created an ontology of functions specific to the modeling system of the navigation system of a spacecraft. The resulting ontology not only links, at an architectural level, language specificinstantiations of the modeling system's code, but also is web-viewable and can act as a documentation standard. This ontology is proof of the concept that ontological modeling can aid in the integration necessary for ISCA to work, and can act as the prototype for future ISCA ontologies.

ontological modeling↗

Athena in 2013 and Beyond

TRISA, the U.S. Army TRADOC G2 Intelligence Support Activity, received Athena 1 in 2009. They first used Athena 3 to support studies in 2011. This paper describes Athena 4, which they started using in October 2012. A final section discusses issues that are being considered for incorporation into Athena 5 and later. Athena's objective is to help skilled intelligence analysts anticipate the likely consequences of complex courses of action that use our country's entire power base, not just our military capabilities, for operations in troubled regions of the world. Measures of effectiveness emphasize who is in control and the effects of our actions on the attitudes and well being of civilians. The planning horizon encompasses not weeks or months, but years.Athena is a scalable, laptop-based simulation with weekly resolution. Up to three months of simulated time can pass between game turns that require user interaction. Athena's geographic scope is nominally a country, but can be a region within a county. Geographic resolution is "neighborhoods", which are defined by the user and may be actual neighborhoods, provinces, or anything in between. Models encompass phenomena whose effects are expected to be relevant over a medium-term planning horizon--three months to three years.The scope and intrinsic complexity of the problem dictate a spiral development process. That is, the model is used during development and lessons learned are used to improve the model. Even more important is that while every version must consider the "big picture" at some level of detail, development priority is given to those issues that are most relevant to currently anticipated studies. For example, models of the delivery and effectiveness of information operations messaging were among the additions in Athena 4.

Diplomatic, Informational, Military, Economic (DIM↗

Reflections on Centaur Upper Stage Integration by the NASA Lewis (Glenn) Research Center

The NASA Glenn (then Lewis) Research Center (GRC) led several expendable launch vehicle (ELV) projects from 1963 to 1998, most notably the Centaur upper stage. These major, comprehensive projects included system management, system development, integration (both payload and stage), and launch operations. The integration role that GRC pioneered was truly unique and highly successful. Its philosophy, scope, and content were not just invaluable to the missions and vehicles it supported, but also had significant Agency-wide benefits. An overview of the NASA Lewis Research Center (now the NASA Glenn Research Center) philosophy on ELV integration is provided, focusing on Atlas/Centaur, Titan/Centaur, and Shuttle/Centaur vehicles and programs. The necessity of having a stable, highly technically competent in-house staff is discussed. Significant depth of technical penetration of contractor work is another critical component. Functioning as a cohesive team was more than a concept: GRC senior management, NASA Headquarters, contractors, payload users, and all staff worked together. The scope, content, and history of launch vehicle integration at GRC are broadly discussed. Payload integration is compared to stage development integration in terms of engineering and organization. Finally, the transition from buying launch vehicles to buying launch services is discussed, and thoughts on future possibilities of employing the successful GRC experience in integrating ELV systems like Centaur are explored.

Centaur↗

Atmospheric Research 2014 Technical Highlights

Atmospheric research in the Earth Sciences Division (610) consists of research and technology development programs dedicated to advancing knowledge and understanding of the atmosphere and its interaction with the climate of Earth. The Division's goals are to improve understanding of the dynamics and physical properties of precipitation, clouds, and aerosols; atmospheric chemistry, including the role of natural and anthropogenic trace species on the ozone balance in the stratosphere and the troposphere; and radiative properties of Earth's atmosphere and the influence of solar variability on the Earth's climate. Major research activities are carried out in the Mesoscale Atmospheric Processes Laboratory, the Climate and Radiation Laboratory, the Atmospheric Chemistry and Dynamics Laboratory, and the Wallops Field Support Office. The overall scope of the research covers an end-to-end process, starting with the identification of scientific problems, leading to observation requirements for remote-sensing platforms, technology and retrieval algorithm development; followed by flight projects and satellite missions; and eventually, resulting in data processing, analyses of measurements, and dissemination from flight projects and missions. Instrument scientists conceive, design, develop, and implement ultraviolet, infrared, optical, radar, laser, and lidar technology to remotely sense the atmosphere. Members of the various Laboratories conduct field measurements for satellite sensor calibration and data validation, and carry out numerous modeling activities. These modeling activities include climate model simulations, modeling the chemistry and transport of trace species on regional-to-global scales, cloud resolving models, and developing the next-generation Earth system models. Satellite missions, field campaigns, peer-reviewed publications, and successful proposals are essential at every stage of the research process to meeting our goals and maintaining leadership of the Earth Sciences Division in atmospheric science research. Figure 1.1 shows the 20-year record of peer-reviewed publications and proposals among the various Laboratories. This data shows that the scientific work being conducted in the Laboratories is competitive with the work being done elsewhere in universities and other government agencies. The office of Deputy Director for Atmospheric Research will strive to maintain this record by rigorously monitoring and promoting quality while emphasizing coordination and integration among atmospheric disciplines. Also, an appropriate balance will be maintained between the scientists' responsibility for large collaborative projects and missions and their need to carry out active science research as a principal investigator. This balance allows members of the Laboratories to improve their scientific credentials, and develop leadership potentials. Interdisciplinary research is carried out in collaboration with other laboratories and research groups within the Earth Sciences Division, across the Sciences and Exploration Directorate, and with partners in universities and other government agencies. Members of the Laboratories interact with the general public to support a wide range of interests in the atmospheric sciences. Among other activities, the Laboratories raise the public's awareness of atmospheric science by presenting public lectures and demonstrations, by making scientific data available to wide audiences, by teaching, and by mentoring students and teachers. The Atmosphere Laboratories make substantial efforts to attract and recruit new scientists to the various areas of atmospheric research. We strongly encourage the establishment of partnerships with Federal and state agencies that have operational responsibilities to promote the societal application of our science products. This report describes our role in NASA's mission, provides highlights of our research scope and activities, and summarizes our scientists' major accomplishments during calendar year 2014. The composition of the organization is shown in Figure 1.2 for each code. This report is published in a printed version with an electronic version on our atmospheres Web site, http://atmospheres.gsfc.nasa.gov/.

Technical↗

Damage Simulation in Composite Materials: Why It Matters and What Is Happening Currently at NASA in This Area

Use of lightweight composite materials in space and aircraft structure designs is often challenging due to high costs associated with structural certification. Of primary concern in the use of composite structures is durability and damage tolerance. This concern is due to the inherent susceptibility of composite materials to both fabrication and service induced flaws. Due to a lack of general industry accepted analysis tools applicable to composites damage simulation, a certification procedure relies almost entirely on testing. It is this reliance on testing, especially compared to structures comprised of legacy metallic materials where damage simulation tools are available, that can drive costs for using composite materials in aerospace structures. The observation that use of composites can be expensive due to testing requirements is not new and as such, research on analysis tools for simulating damage in composite structures has been occurring for several decades. A convenient approach many researchers/model-developers in this area have taken is to select a specific problem relevant to aerospace structural certification and develop a model that is accurate within that scope. Some examples are open hole tension tests, compression after impact tests, low-velocity impact, damage tolerance of an embedded flaw, and fatigue crack growth to name a few. Based on the premise that running analyses is cheaper than running tests, one motivation that many researchers in this area have is that if generally applicable and reliable damage simulation tools were available the dependence on certification testing could be lessened thereby reducing overall design cost. It is generally accepted that simulation tools if applied in this manner would still need to be thoroughly validated and that composite testing will never be completely replaced by analysis. Research and development is currently occurring at NASA to create numerical damage simulation tools applicable to damage in composites. The Advanced Composites Project (ACP) at NASA Langley has supported the development of composites damage simulation tools in a consortium of aerospace companies with a goal of reducing the certification time of a commercial aircraft by 30%. And while the scope of ACP does not include spacecraft, much of the methodology and simulation capabilities can apply to spacecraft certification in the Space Launch System and Orion programs as well. Some specific applications of composite damage simulation models in a certification program are (1) evaluation of damage during service when maintenance may be difficult or impossible, (2) a tool for early design iterations, (3) gaining insight into a particular damage process and applying this insight towards a test coupon or structural design, and (4) analysis of damage scenarios that are difficult or impossible to recreate in a test. As analysis capabilities improve, these applications and more will become realized resulting in a reduction in cost for use of composites in aerospace vehicles. NASA is engaged in this process from both research and application perspectives. In addition to the background information discussed previously, this presentation covers a look at recent research at NASA in this area and some current/potential applications in the Orion program.

McElroy, Mack↗

Increasing Small Satellite Reliability- A Public-Private Initiative

At present, CubeSat components and buses are generally not appropriate for missions where significant risk of failure, or the inability to quantify risk or confidence, is acceptable. However, in the future we anticipate that CubeSats will be used for missions requiring reliability of 1-3 years for Earth-observing missions and even longer for Planetary, Heliophysics, and Astrophysics missions. Their growing potential utility is driving an interagency effort to improve and quantify CubeSat reliability, and more generally, small satellite mission risk. The Small Satellite Reliability Initiative (SSRI)—an ongoing activity with broad collaborative participation from civil, DoD, and commercial space systems providers and stakeholders—targets this challenge. The Initiative seeks to define implementable and broadly-accepted approaches to achieve reliability and acceptable risk postures associated with several SmallSat mission risk classes—from “do no harm” missions, to those associated with missions whose failure would result in loss or delay of key national objectives. These approaches will maintain, to the extent practical, cost efficiencies associated with small satellite missions and consider constraints associated with supply chain elements, as appropriate. The SSRI addresses this challenge from two architectural levels—the mission- or system-level, and the component- or subsystem-level. The mission- or system-level scope targets assessment approaches that are efficient and effective, with mitigation strategies that facilitate resiliency to mission or system anomalies while the component- or subsystem-level scope addresses the challenge at lower architectural levels. The initiative does not limit strategies and approaches to proven and traditional methodologies, but is focused on fomenting thought on novel and innovative solutions. This paper discusses the genesis of and drivers for this initiative, how the public-private collaboration is being executed, findings and recommendations derived to date, and next steps towards broadening small satellite mission potential.

SmallSat↗