Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “technical management”

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 307 records · Page 17

NASA's Space Environments and Effects (SEE) Program: The Pursuit of Tomorrow's Space Technology

A hazard to all spacecraft orbiting the earth and exploring the unknown in deep space is the existence of a harsh and ever changing environment with its subsequent effects. Some of these environmental hazards, such as plasma, extreme thermal excursions, meteoroids, and ionizing radiation result from natural sources, whereas others, such as orbital debris and neutral contamination are induced by the presence of spacecraft themselves. The subsequent effects can provide damaging or even disabling effects on spacecraft, its materials, and its instruments. In partnership with industry, academia, and other government agencies, National Aeronautics & Space Administration's (NASA's) Space Environments & Effects (SEE) Program defines the space environments and advocates technology development to accommodate or mitigate these harmful environments on the spacecraft. This program provides a very comprehensive and focused approach to understanding the space environment, to define the best techniques for both flight and ground-based experimentation, to update the models which predict both the environments and the environmental effects on spacecraft, and finally to ensure that this information is properly maintained and inserted into spacecraft design programs. This paper will provide an overview of the Program's purpose, goals, database management and technical activities. In particular, the SEE Program has been very active in developing improved ionizing radiation models and developing related flight experiments which should aid in determining the effect of the radiation environment on modern electronics.

Pearson, Steven D.↗

Warning: Projects May Be Closer than They Appear

I had been working for two years as the technical product manager for a large software company, when their partner company gave me a call. They needed good software engineers to customize a new version of software, and they thought I was their guy. They told me what they wanted to do to the software, and they even showed me some prototypes. Their idea was to take the basic software tool that the large company was producing and make it more accessible to the customer. They would do this by building in flexibility based on user skill level and organizational maturity. I thought that was a fascinating approach, and I bought into it in a big way. I decided to leave my job and join up with the smaller company as their director of software engineering.

Africa, Colby↗

Space Electronic Test Engineering

The Space Power and Propulsion Test Engineering Branch at NASA Glenn Research center has the important duty of controlling electronic test engineering services. These services include test planning and early assessment of Space projects, management and/or technical support required to safely and effectively prepare the article and facility for testing, operation of test facilities, and validation/delivery of data to customer. The Space Electronic Test Engineering Branch is assigned electronic test engineering responsibility for the GRC Space Simulation, Microgravity, Cryogenic, and Combustion Test Facilities. While working with the Space Power and Propulsion Test Engineering Branch I am working on several different assignments. My primary assignment deals with an electrical hardware unit known as Sunny Boy. Sunny Boy is a DC load Bank that is designed for solar arrays in which it is used to convert DC power form the solar arrays into AC power at 60 hertz to pump back into the electricity grid. However, there are some researchers who decided that they would like to use the Sunny Boy unit in a space simulation as a DC load bank for a space shuttle or even the International Space Station hardware. In order to do so I must create a communication link between a computer and the Sunny Boy unit so that I can preset a few of the limits (such power, set & constant voltage levels) that Sunny Boy will need to operate using the applied DC load. Apart from this assignment I am also working on a hi-tech circuit that I need to have built at a researcher s request. This is a high voltage analog to digital circuit that will be used to record data from space ion propulsion rocket booster tests. The problem that makes building this circuit so difficult is that it contains high voltage we must find a way to lower the voltage signal before the data is transferred into the computer to be read. The solution to this problem was to transport the signal using infrared light which will lower the voltage signal down low enough so that it is harmless to a computer. Along with my involvement in the Space Power and Propulsion Test Engineering Branch, I am obligated to assist all other members of the branch in their work. This will help me to strengthen and extend my knowledge of Electrical Engineering.

Chambers, Rodney D.↗

Lithium-Ion Polymer Rechargeable Battery Developed for Aerospace and Military Applications

A recently completed 3 -year project funded by the Defense Advanced Research Projects Agency (DARPA) under the Technology Reinvestment Program has resulted in the development and scaleup of new lithium-ion polymer battery technology for military and aerospace applications. The contractors for this cost-shared project were Lockheed Martin Missiles & Space and Ultralife Batteries, Inc. The NASA Lewis Research Center provided contract management and technical oversight. The final products of the project were a portable 15-volt (V), 10-ampere-hour (A-hr) military radio battery and a 30-V, 50-A-hr marine/aerospace battery. Lewis will test the 50-A-hr battery. The new lithium-ion polymer battery technology offers a threefold or fourfold reduction in mass and volume, relative to today s commonly used nickel-cadmium, nickel-hydrogen, and nickel-metal hydride batteries. This is of special importance for orbiting satellites. It has been determined for a particular commercial communications satellite that the replacement of 1 kg of battery mass with 1 kg of transponder mass could increase the annual revenue flow by $100 000! Since this lithium-ion polymer technology offers battery mass reductions on the order of hundreds of kilograms for some satellites, the potential revenue increases are impressive.

Hagedorn, orman H.↗

Decision Facilitator for Launch Operations using Intelligent Agents

Launch operations require millions of micro-decisions which contribute to the macro decision of 'Go/No-Go' for a launch. Knowledge workers"(such as managers and technical professionals) need information in a timely precise manner as it can greatly affect mission success. The intelligent agent (web search agent) uses the words of a hypertext markup language document which is connected through the internet. The intelligent agent's actions are to determine if its goal of seeking a website containing a specified target (e.g., keyword or phrase), has been met. There are few parameters that should be defined for the keyword search like "Go" and "No-Go". Instead of visiting launch and range decision making servers individually, the decision facilitator constantly connects to all servers, accumulating decisions so the final decision can be decided in a timely manner. The facilitator agent uses the singleton design pattern, which ensures that only a single instance of the facilitator agent exists at one time. Negotiations could proceed between many agents resulting in a final decision. This paper describes details of intelligent agents and their interaction to derive an unified decision support system.

Thirumalainambi, Rajkumar↗

Prometheus Project final report

This Final Report serves as an executive summary of the Prometheus Project's activities and deliverables from November 2002 through September 2005. It focuses on the challenges from a technical and management perspective, what was different and innovative about this project, and identifies the major options, decisions, and accomplishments of the Project team as a whole. However, the details of the activities performed by DOE NR and its contractors will be documented separately in accordance with closeout requirements of the DOE NR and consistent with agreements between NASA and NR.

Prometheus Project↗

Launch and Landing Effects Ground Operations (LLEGO) Model

LLEGO is a model for understanding recurring launch and landing operations costs at Kennedy Space Center for human space flight. Launch and landing operations are often referred to as ground processing, or ground operations. Currently, this function is specific to the ground operations for the Space Shuttle Space Transportation System within the Space Shuttle Program. The Constellation system to follow the Space Shuttle consists of the crewed Orion spacecraft atop an Ares I launch vehicle and the uncrewed Ares V cargo launch vehicle. The Constellation flight and ground systems build upon many elements of the existing Shuttle flight and ground hardware, as well as upon existing organizations and processes. In turn, the LLEGO model builds upon past ground operations research, modeling, data, and experience in estimating for future programs. Rather than to simply provide estimates, the LLEGO model s main purpose is to improve expenses by relating complex relationships among functions (ground operations contractor, subcontractors, civil service technical, center management, operations, etc.) to tangible drivers. Drivers include flight system complexity and reliability, as well as operations and supply chain management processes and technology. Together these factors define the operability and potential improvements for any future system, from the most direct to the least direct expenses.

Source record↗

Qualification of Electrical Ground Support Equipment for New Space Programs

With the Space Shuttle program coming to an end, the National Aeronautics and Space Administration (NASA) is moving to a new space flight program that will allow expeditions beyond low earth orbit. The space vehicles required to comply with these missions will be carrying heavy payloads. This implies that the Earth departure stage capabilities must be of higher magnitudes, given the current propulsion technology. The engineering design of the new flight hardware comes with some structural, thermal, propulsion and other subsystems' challenges. Meanwhile, the necessary ground support equipment (GSE) used to test, validate, verify and process the flight hardware must withstand the new program specifications. This paper intends to provide the qualification considerations during implementation of new electrical GSE for space programs. A team of engineers was formed to embark on this task, and facilitate the logistics process and ensure that the electrical, mechanical and fluids subsystems conduct the proper level of testing. Ultimately, each subsystem must certify that each piece of ground support equipment used in the field is capable of withstanding the strenuous vibration, acoustics, environmental, thermal and Electromagnetic Interference (EMf) levels experienced during pre-launch, launch and post-launch activities. The benefits of capturing and sharing these findings will provide technical, cost savings and schedule impacts infon11ation to both the technical and management community. Keywords: Qualification; Testing; Ground Support Equipment; Electromagnetic Interference Testing; Vibration Testing; Acoustic Testing; Power Spectral Density.

SotoToro, Felix A.↗

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

Apollo, Paintbrushes, and Packaging: An Interview with 40-Year Spacesuit Veteran Ron Woods

Ron Woods exhibits a wealth of knowledge gathered in more than 40 years of experience with NASA and spacesuits. Many people are interested in his biography, progression of work at NASA, impact on the U.S. Spacesuit, and career accomplishments. Wright, from the JSC History Office, conducted this personal background interview with Woods. The interview highlighted the influences and decision-making methods that impacted his technical and management contributions to the space program.

Woods, Ron↗

UTM TCL 2.0 Software Version Description (SVD) Document

This is the Unmanned Aircraft Systems (UAS) Traffic Management (UTM) Technical Capability Level(TCL) 2.0 Software Version Description (SVD) document. This UTM TCL 2.0 SVD describes the following four topics: 1. Software Release Contents: A listing of the files comprising this release 2. Installation Instructions: How to install the release and get it running 3. Changes Since Previous Release: General updates since the previous UTM release 4. Known Issues: Known issues and limitations in this release

Mcguirk, Patrick↗

UTM TCL2 Software Requirements

The Unmanned Aircraft Systems (UAS) Traffic Management (UTM) Technical Capability Level (TCL) 2 software implements the UTM TCL 2 software requirements described herein. These software requirements are linked to the higher level UTM TCL 2 System Requirements. Each successive TCL implements additional UTM functionality, enabling additional use cases. TCL 2 demonstrated how to enable expanded multiple operations by implementing automation for beyond visual line-of-sight, tracking operations, and operations flying over sparsely populated areas.

Smith, Irene S.↗

Digital Model-Based Engineering: Expectations, Prerequisites, and Challenges of Infusion

Digital model-based engineering (DMbE) is the use of digital artifacts, digital environments, and digital tools in the performance of engineering functions. DMbE is intended to allow an organization to progress from documentation-based engineering methods to digital methods that may provide greater flexibility, agility, and efficiency. The term 'DMbE' was developed as part of an effort by the Model-Based Systems Engineering (MBSE) Infusion Task team to identify what government organizations might expect in the course of moving to or infusing MBSE into their organizations. The Task team was established by the Interagency Working Group on Engineering Complex Systems, an informal collaboration among government systems engineering organizations. This Technical Memorandum (TM) discusses the work of the MBSE Infusion Task team to date. The Task team identified prerequisites, expectations, initial challenges, and recommendations for areas of study to pursue, as well as examples of efforts already in progress. The team identified the following five expectations associated with DMbE infusion, discussed further in this TM: (1) Informed decision making through increased transparency, and greater insight. (2) Enhanced communication. (3) Increased understanding for greater flexibility/adaptability in design. (4) Increased confidence that the capability will perform as expected. (5) Increased efficiency. The team identified the following seven challenges an organization might encounter when looking to infuse DMbE: (1) Assessing value added to the organization. Not all DMbE practices will be applicable to every situation in every organization, and not all implementations will have positive results. (2) Overcoming organizational and cultural hurdles. (3) Adopting contractual practices and technical data management. (4) Redefining configuration management. The DMbE environment changes the range of configuration information to be managed to include performance and design models, database objects, as well as more traditional book-form objects and formats. (5) Developing information technology (IT) infrastructure. Approaches to implementing critical, enabling IT infrastructure capabilities must be flexible, reconfigurable, and updatable. (6) Ensuring security of the single source of truth (7) Potential overreliance on quantitative data over qualitative data. Executable/ computational models and simulations generally incorporate and generate quantitative vice qualitative data. The Task team also developed several recommendations for government, academia, and industry, as discussed in this TM. The Task team recommends continuing beyond this initial work to further develop the means of implementing DMbE and to look for opportunities to collaborate and share best practices.

Hale, J. P.↗

Using A Model-Based Systems Engineering Approach For Exploration Medical System Development

NASA's Human Research Program's Exploration Medical Capabilities (ExMC) element is defining the medical system needs for exploration class missions. ExMC's Systems Engineering (SE) team will play a critical role in successful design and implementation of the medical system into exploration vehicles. The team's mission is to "Define, develop, validate, and manage the technical system design needed to implement exploration medical capabilities for Mars and test the design in a progression of proving grounds." Development of the medical system is being conducted in parallel with exploration mission architecture and vehicle design development. Successful implementation of the medical system in this environment will require a robust systems engineering approach to enable technical communication across communities to create a common mental model of the emergent engineering and medical systems. Model-Based Systems Engineering (MBSE) improves shared understanding of system needs and constraints between stakeholders and offers a common language for analysis. The ExMC SE team is using MBSE techniques to define operational needs, decompose requirements and architecture, and identify medical capabilities needed to support human exploration. Systems Modeling Language (SysML) is the specific language the SE team is utilizing, within an MBSE approach, to model the medical system functional needs, requirements, and architecture. Modeling methods are being developed through the practice of MBSE within the team, and tools are being selected to support meta-data exchange as integration points to other system models are identified. Use of MBSE is supporting the development of relationships across disciplines and NASA Centers to build trust and enable teamwork, enhance visibility of team goals, foster a culture of unbiased learning and serving, and be responsive to customer needs. The MBSE approach to medical system design offers a paradigm shift toward greater integration between vehicle and the medical system and directly supports the transition of Earth-reliant ISS operations to the Earth-independent operations envisioned for Mars. Here, we describe the methods and approach to building this integrated model.

Hanson, A.↗

Exploration Medical Capability System Engineering Overview

Deep Space Gateway and Transport missions will change the way NASA currently practices medicine. The missions will require more autonomous capability compared to current low Earth orbit operations. For the medical system, lack of consumable resupply, evacuation opportunities, and real-time ground support are key drivers toward greater autonomy. Recognition of the limited mission and vehicle resources available to carry out exploration missions motivates the Exploration Medical Capability (ExMC) Element's approach to enabling the necessary autonomy. The ExMC Systems Engineering team's mission is to "Define, develop, validate, and manage the technical system design needed to implement exploration medical capabilities for Mars and test the design in a progression of proving grounds." The Element's work must integrate with the overall exploration mission and vehicle design efforts to successfully provide exploration medical capabilities. ExMC is using Model-Based System Engineering (MBSE) to accomplish its integrative goals. The MBSE approach to medical system design offers a paradigm shift toward greater integration between vehicle and the medical system, and directly supports the transition of Earth-reliant ISS operations to the Earth-independent operations envisioned for Mars. This talk will discuss how ExMC is using MBSE to define operational needs, decompose requirements and architecture, and identify medical capabilities needed to support human exploration. How MBSE is being used to integrate across disciplines and NASA Centers will also be described. The medical system being discussed in this talk is one system within larger habitat systems. Data generated within the medical system will be inputs to other systems and vice versa. This talk will also describe the next steps in model development that include: modeling the different systems that comprise the larger system and interact with the medical system, understanding how the various systems work together, and developing tools to support trade studies.

Mindock, J.↗