SEARCH · Engineering Papers
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.
Dan Harrison will discuss overcoming institutional and cultural obstacles that he encountered during his more than 35-year career in engineering and engineering management. He will discuss why it is important to challenge the "unwritten laws" and the status quo that large organizations develop that are contrary to the end-goal of safe, affordable space exploration.
My internship was in the IDC which consist of a machine shop and an array of design space. During my tour I worked on a wide variety of projects some of which included design, research, machining and fabrication. I gained further knowledge on some machines that I have had prior experience on such as the lathe and Hurco CNC machines. The first thing we did was complete our checkout in the machine shop which went pretty well, since I was already familiar with most of the machines. I also did a couple of practice parts on some of the machines, I made a name block on the CNC machine and I also used the vertical milling machine to complete this project. One of the other projects that I did was machine a hammer with my initials with the use of the lathe and CNC machine, this project took much longer since I had to set up a cylindrical piece on the CNC machine. The first project that I began work on was the Systems Engineering & Management Advancement Program (SEPMAP) Hexacopter project and helped them to assemble and modify one of their particle capture doors on their boxes. After a while we ended up helping them make a hinge and holes to reduce the weight of their design. We helped the NASA Extreme Environment Mission Operations (NEEMO) team a bit with some of their name tags and assembly of some of their underwater parts. One of the more challenging projects was a rail that came in with a rather weirdly drawn part. The biggest project that I worked on was the solar array project. Which consisted of a variety of machining and 3D printing and it took me about 3 different times of re-designing to come up with a final prototype. Along with this project I also had to complete a project in which I had to modify a thermos. This was rather simple since I just had to draw up a part and print it out on the 3D printer. I also learned how to use Pro E/Creo parametric to design a square block and print it on the 3D Printer. All of these projects increased my experience on all of the machines and equipment that I used. I also got to tweak my design skills and better understand how to modify my designs and how to improve those specific designs.
To ensure that the NASA Safety and Mission Assurance (SMA) community remains in a position to perform reliable Software Assurance (SA) on NASAs critical software (SW) systems with the software industry rapidly transitioning from waterfall to Agile processes, Terry Wilcutt, Chief, Safety and Mission Assurance, Office of Safety and Mission Assurance (OSMA) established the Agile Benchmarking Team (ABT). The Team's tasks were: 1. Research background literature on current Agile processes, 2. Perform benchmark activities with other organizations that are involved in software Agile processes to determine best practices, 3. Collect information on Agile-developed systems to enable improvements to the current NASA standards and processes to enhance their ability to perform reliable software assurance on NASA Agile-developed systems, 4. Suggest additional guidance and recommendations for updates to those standards and processes, as needed. The ABT's findings and recommendations for software management, engineering and software assurance are addressed herein.
Integration and test (I&T) of the Lunar Atmosphere and Dust Environment Explorer (LADEE) is presented. A collaborative NASA project between Goddard Space Flight Center and Ames Research Center, LADEE's mission is to explore the low lunar orbit environment and exosphere for constituents. Its instruments include two spectrometers, a dust detector, and a laser communication technology demonstration. Although a relatively low-cost spacecraft, LADEE has I&T requirements typical of most planetary probes, such as prelaunch contamination control, sterilization, and instrument calibration. To lead to a successful mission, I&T at the spacecraft, instrument, and observatory level must include step-by-step and end-to-end functional, environmental, and performance testing. Due to its compressed development schedule, LADEE I&T planning requires adjusting test flows and sequences to account for long-lead critical-path items and limited spares. A protoflight test-level strategy is also baselined. However, the program benefits from having two independent but collaborative teams of engineers, managers, and technicians that have a wealth of flight project experience. This paper summarizes the LADEE I&T planning, flow, facilities, and probe-unique processes. Coordination of requirements and approaches to I&T when multiple organizations are involved is discussed. Also presented are cost-effective approaches to I&T that are transferable to most any spaceflight project I&T program.
OSIRIS-REx will return pristine samples of carbonaceous asteroid Bennu. This article describes how pristine was defined based on expectations of Bennu and on a realistic understanding of what is achievable with a constrained schedule and budget, and how that definition flowed to requirements and implementation. To return a pristine sample, the OSIRIS-REx spacecraft sampling hardware was maintained at level 100 A/2 and less than 180 ng/cm(exp 2) of amino acids and hydrazine on the sampler head through precision cleaning, control of materials, and vigilance. Contamination is further characterized via witness material exposed to the spacecraft assembly and testing environment as well as in space. This characterization provided knowledge of the expected background and will be used in conjunction with archived spacecraft components for comparison with the samples when they are delivered to Earth for analysis. Most of all, the cleanliness of the OSIRIS-REx spacecraft was achieved through communication among scientists, engineers, managers, and technicians.
OSIRIS-REx will return pristine samples of carbonaceous asteroid Bennu. This manuscript describes how pristine was defined based on expectations of Bennu and on a realistic understanding of what is achievable with a constrained schedule and budget, and how that definition flowed to requirements and implementation. To return a pristine sample, the OSIRIS-REx spacecraft sampling hardware was maintained at Level 100 A/2 and less than 180 nanograms per square centimeter of amino acids and hydrazine on the sampler head through precision cleaning, control of materials, and vigilance. Contamination is further characterized via witness material exposed to the spacecraft assembly and testing environment as well as in space. This characterization provided knowledge of the expected background and will be used in conjunction with archived spacecraft components for comparison with the samples when they are delivered to Earth for analysis. Most of all, the cleanliness of the OSIRIS-REx spacecraft was achieved through communication between scientists, engineers, managers, and technicians.
Understanding the needs of the end user is vital to producing quality, usable software that solves real problems. Additionally, making sure those needs are communicated to managers, engineers, and designers at the project level is vital. On complex projects, it's important to build out resources for your team that make it easy to put yourself in the shoes of the specific user you're building for. NASA's Earth Observing System is a collection of data, applications, and a diverse user and scientific community that's trying to answer tough questions about our planet and its climate. Over the last few years, we've spoken to hundreds of users, performed many user testing sessions, and built a collection of user personas, user stories, and design assets that help guide new software and feature development within NASA EOSDIS. We've also developed methods for synthesizing this information and making it actionable for teams, and worked to foster a design first approach on new projects always starting from a core user need and working backward from interface development to software engineering. This process has allowed us to design better, more usable software and features that directly meet the needs of our user community.
The NASA SIO demonstration flight of April 3, 2020 represents a successful culmination of 18 months of coordinated effort between GA-ASI, NASA, the FAA, Collins Aerospace, and Honeywell Aerospace to operate a Medium Altitude, Long Endurance (MALE) Unmanned Aircraft System (UAS) safely in the National Airspace System (NAS) using industry leading prototype technologies. The GA-ASI team consisted of technical experts, program managers, engineers, mechanics, flight technicians, flight crews, and numerous other subject matter experts. This final report describes the most significant and potentially impactful aspects of the planning, integration, test, and flight aspects of this effort. GA-ASI successfully integrated the key technologies needed for UAS to fly in the NAS onto our prototype SkyGuardian UAS, which was designed to meet the most stringent airworthiness standards applicable to an aircraft of its size category. A proven Detect and Avoid (DAA) system, developed by GA-ASI and utilizing Honeywell Aerospace technology was integrated onto SkyGuardian for the first time, along with datalink radios from Collins Aerospace that meet the new civil standard for Control and Non-Payload Communication (CNPC) links. GA-ASI also obtained approvals from the FAA and FCC to operate the reconfigured UAS. The SIO demonstration flight represented a commercial aerial surveying operation conducted at medium altitude (>10,000ft above mean sea level). The aircraft’s onboard sensors were used to capture photographic, infrared and radar imagery of public and commercial infrastructure and land, and to subsequently produce the types of data products that would provide business value to potential customers. These survey services would supplement or replace services currently provided by manned airplanes and helicopters, small drones or satellites. A “virtual” mission was also planned, to show what additional survey data could have been captured during the flight if additional sensors had been installed on the aircraft’s external hardpoints. This revision of the final report focuses on information of value to the wider UAS community, and avoids propriety data to facilitate broad dissemination. It also includes a description of GA-ASI’s engagement with the FAA following the SIO flight, which led to the award of an updated Special Airworthiness Certificate in the Experimental Category (SAC-EC) and a Certificate of Waiver or Authorization (COA) allowing operation of the SkyGuardian UAS using its DAA system to satisfy right-of-way rules, instead of a chase plane. The associated operational limitations are described to illustrate the further steps that would be needed to remove those limitations for unhindered commercial operations.
False beliefs about new ideas are not new. They happen all the time, for a wide variety of reasons. Although the Overarching Properties are solidly grounded in time-honored principles, they constitute a novel expression of those ideas, and newness-based false beliefs about them are to be expected. Similarly, although Overarching Properties Related Arguments are solidly grounded in thousands of years of study of the principles of argumentation, they introduce concepts and applications that are novel to many engineers and engineering managers. So, false beliefs about them are also to be expected. Indeed, false beliefs have arisen and are spreading in the wild about both the Overarching Properties and Overarching Properties Related Arguments. This paper seeks to dispel three known false beliefs about each concept.
The design of the science planning process for a space science mission needs to find a balance between operational and resource constraints and scientific decision-making. Science planning has previously been characterized as either predictive or reactive. Predictive science planning is needed when constraints drive science activities to be planned far in advance. For example, a combination of long one-way light time plus high-stakes science decisions drove the Cassini-Huygens mission to Saturn to have an extremely predictive planning process. On the other extreme, reactive science planning is needed when constraints drive science activities to be planned based on the results of the previous plan. For example, the Mars Exploration Rover mission interacted with the surface of Mars, and so the planning team needed to know the state of the rover at the end of each planning cycle before starting the next cycle. Operational and resource constraints that require management on intermediate timescales has led to the development of a science planning process between these two extremes. For example, the Mars Science Laboratory is a technically complex rover and has a parallel predictive process that allows the operations team to manage engineering constraints several days in advance while maintaining the reactive tactical planning process similar to that of MER. The Mars 2020 Perseverance rover is a technically complex rover in the MSL style, but has an added layer of science complexity: it is tasked with collecting a returnable cache of scientifically valuable samples of Mars within prime mission. Thus, the science planning process also needs to accommodate high-stakes longer-term science decisions in the style of Cassini. In order to balance the push-pull of these constraints, we have developed a science campaign-focused operational paradigm for Mars 2020 Perseverance that allows for both predictive planning to accommodate technological complexity and high-stakes science decisions as well as reactive planning to accommodate the realities of interacting with the martian surface. This paradigm influenced the design of operational processes and operational tools.
Data elements and relationship definition capabilities for this data management system are explicitly tailored to the needs of engineering and scientific computing. System design was based upon studies of data management problems currently being handled through explicit programming. The system-defined data element types include real scalar numbers, vectors, arrays and special classes of arrays such as sparse arrays and triangular arrays. The data model is hierarchical (tree structured). Multiple views of data are provided at two levels. Subschemas provide multiple structural views of the total data base and multiple mappings for individual record types are supported through the use of a REDEFINES capability. The data definition language and the data manipulation language are designed as extensions to FORTRAN. Examples of the coding of real problems taken from existing practice in the data definition language and the data manipulation language are given.
Predicting, managing, controlling, and testing spacecraft line-of-sight (LoS) jitter caused by micro-vibrations due to onboard internal disturbance sources is a formidable multidisciplinary engineering task. It is especially challenging for those missions hosting high-performance, vibration-sensitive optical sensor payloads with stringent pointing stability requirements. Both NASA and ESA are planning technically aggressive spaceflight missions that include ultra-high-performance optical payloads with delicate, highly vibration-sensitive scientific and observational instruments. The GN&C community of practice will need to leverage and build upon their collective experiences and lessons learned to better address future micro-vibration challenges. To identify lessons learned and best engineering practices the NASA Engineering & Safety Center (NESC) sponsored a two-day Spacecraft LoS Jitter Workshop in late 2019. The workshop’s goal was to provide a multidisciplinary forum to elicit deeper understanding of the issues related to solving the spacecraft LoS jitter/micro-vibration problem. A primary objective was to identify and share best practices, rules of thumb, and options for jitter-related activities. Representatives from NASA, JPL, ESA, along with NASA’s industrial partners, independent consultant subject matter experts, and members of academia participated in the workshop. This paper will describe the motivation for the NASA Spacecraft LoS Jitter Workshop and summarize the identified findings, observations, and recommendations.
The draft NASA Fault Management (FM) Handbook (2012) states that Fault Management (FM) is a "part of systems engineering", and that it "demands a system-level perspective" (NASAHDBK- 1002, 7). What, exactly, is the relationship between systems engineering and FM? To NASA, systems engineering (SE) is "the art and science of developing an operable system capable of meeting requirements within often opposed constraints" (NASA/SP-2007-6105, 3). Systems engineering starts with the elucidation and development of requirements, which set the goals that the system is to achieve. To achieve these goals, the systems engineer typically defines functions, and the functions in turn are the basis for design trades to determine the best means to perform the functions. System Health Management (SHM), by contrast, defines "the capabilities of a system that preserve the system's ability to function as intended" (Johnson et al., 2011, 3). Fault Management, in turn, is the operational subset of SHM, which detects current or future failures, and takes operational measures to prevent or respond to these failures. Failure, in turn, is the "unacceptable performance of intended function." (Johnson 2011, 605) Thus the relationship of SE to FM is that SE defines the functions and the design to perform those functions to meet system goals and requirements, while FM detects the inability to perform those functions and takes action. SHM and FM are in essence "the dark side" of SE. For every function to be performed (SE), there is the possibility that it is not successfully performed (SHM); FM defines the means to operationally detect and respond to this lack of success. We can also describe this in terms of goals: for every goal to be achieved, there is the possibility that it is not achieved; FM defines the means to operationally detect and respond to this inability to achieve the goal. This brief description of relationships between SE, SHM, and FM provide hints to a modeling approach to provide formal connectivity between the nominal (SE), and off-nominal (SHM and FM) aspects of functions and designs. This paper describes a formal modeling approach to the initial phases of the development process that integrates the nominal and off-nominal perspectives in a model that unites SE goals and functions of with the failure to achieve goals and functions (SHM/FM). This methodology and corresponding model, known as a Goal-Function Tree (GFT), provides a means to represent, decompose, and elaborate system goals and functions in a rigorous manner that connects directly to design through use of state variables that translate natural language requirements and goals into logical-physical state language. The state variable-based approach also provides the means to directly connect FM to the design, by specifying the range in which state variables must be controlled to achieve goals, and conversely, the failures that exist if system behavior go out-of-range. This in turn allows for the systems engineers and SHM/FM engineers to determine which state variables to monitor, and what action(s) to take should the system fail to achieve that goal. In sum, the GFT representation provides a unified approach to early-phase SE and FM development. This representation and methodology has been successfully developed and implemented using Systems Modeling Language (SysML) on the NASA Space Launch System (SLS) Program. It enabled early design trade studies of failure detection coverage to ensure complete detection coverage of all crew-threatening failures. The representation maps directly both to FM algorithm designs, and to failure scenario definitions needed for design analysis and testing. The GFT representation provided the basis for mapping of abort triggers into scenarios, both needed for initial, and successful quantitative analyses of abort effectiveness (detection and response to crew-threatening events).
The draft NASA Fault Management (FM) Handbook (2012) states that Fault Management (FM) is a "part of systems engineering", and that it "demands a system-level perspective" (NASAHDBK- 1002, 7). What, exactly, is the relationship between systems engineering and FM? To NASA, systems engineering (SE) is "the art and science of developing an operable system capable of meeting requirements within often opposed constraints" (NASA/SP-2007-6105, 3). Systems engineering starts with the elucidation and development of requirements, which set the goals that the system is to achieve. To achieve these goals, the systems engineer typically defines functions, and the functions in turn are the basis for design trades to determine the best means to perform the functions. System Health Management (SHM), by contrast, defines "the capabilities of a system that preserve the system's ability to function as intended" (Johnson et al., 2011, 3). Fault Management, in turn, is the operational subset of SHM, which detects current or future failures, and takes operational measures to prevent or respond to these failures. Failure, in turn, is the "unacceptable performance of intended function." (Johnson 2011, 605) Thus the relationship of SE to FM is that SE defines the functions and the design to perform those functions to meet system goals and requirements, while FM detects the inability to perform those functions and takes action. SHM and FM are in essence "the dark side" of SE. For every function to be performed (SE), there is the possibility that it is not successfully performed (SHM); FM defines the means to operationally detect and respond to this lack of success. We can also describe this in terms of goals: for every goal to be achieved, there is the possibility that it is not achieved; FM defines the means to operationally detect and respond to this inability to achieve the goal. This brief description of relationships between SE, SHM, and FM provide hints to a modeling approach to provide formal connectivity between the nominal (SE), and off-nominal (SHM and FM) aspects of functions and designs. This paper describes a formal modeling approach to the initial phases of the development process that integrates the nominal and off-nominal perspectives in a model that unites SE goals and functions of with the failure to achieve goals and functions (SHM/FM).
In the development of complex spacecraft missions, project management authority is usually extended hierarchically from NASA's highest agency levels down to the implementing institution's project team level, through both the center and the program. In parallel with management authority, NASA utilizes a complementary, but independent, hierarchy of technical authority (TA) that extends from the agency level to the project, again, through both the center and the program. The chief engineers (CEs) who serve in this technical authority capacity oversee and report on the technical status and ensure sound engineering practices, controls, and management of the projects and programs. At the lowest level, implementing institutions assign project CEs to technically engage projects, lead development teams, and ensure sound technical principles, processes, and issue resolution. At the middle level, programs and centers independently use CEs to ensure the technical success of their projects and programs. At the agency level, NASA's mission directorate CEs maintain technical cognizance over every program and project in their directorate and advise directorate management on the technical, cost, schedule, and programmatic health of each. As part of this vertically-extended CE team, a program level CE manages a continually varying balance between penetration depth and breadth across his or her assigned missions. Teamwork issues and information integration become critical for management at all levels to ensure value-added use of both the synergy available between CEs at the various agency levels, and the independence of the technical authority at each organization.
Many engineering methods have been developed to help management select technology for a system design or further research. The simplest way to compare technologies is to use a checklist containing all the more or less important selection criteria, so that nothing is overlooked. The criteria usually include cost, safety, reliability and maintainability, and potential problems such as noise generation and microgravity sensitivity. The next step typically is to weight and score all the criteria. The process of weighting and scoring is helpful in bringing out different priorities and reaching a shared point of view. Group technology selection methods are designed to highlight initial disagreements and produce a shared consensus. Often a frank discussion led by management rather than decision analysts can be more effective. The final selection depends on management and engineering judgment and may include programmatic and organizational factors that are beyond the engineering checklist. The objective of engineering technology selection methods is to provide engineering information to assist management in making sound decisions. Project management and technology selection are assumed to use rational engineering analytic methods, but they often do not. The reason is that human insight, intuition, and “gut feel,” rather than logic, more frequently determine our decisions. Project selection and management are strongly influenced by nonrational psychological influences, which can produce unjustified confidence and determination. Nevertheless, there is a strong need for space projects to do rational project analysis and selection. Demonstrating a rational spirit is necessary for a scientific and technical organization. Professional ethics at its best requires an open, honest, and fair process, without damaging politics. Rational analysis can help improve good projects and avoid selecting bad ones. A sanity check using rational analysis guided by a checklist can help avoid egregious and damaging errors.
The application of data management systems to engineering and scientific data is described.
When applied to a system, the doctrine of successive refinement is a divide-and-conquer strategy. Complex systems are sucessively divided into pieces that are less complex, until they are simple enough to be conquered. This decomposition results in several structures for describing the product system and the producing system. These structures play important roles in systems engineering and project management. Many of the remaining sections in this chapter are devoted to describing some of these key structures. Structures that describe the product system include, but are not limited to, the requirements tree, system architecture and certain symbolic information such as system drawings, schematics, and data bases. The structures that describe the producing system include the project's work breakdown, schedules, cost accounts and organization.