Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “lifecycle”

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 325 records · Page 18

SOFIA Program SE and I Lessons Learned

Once a "Troubled Project" threatened with cancellation, the Stratospheric Observatory for Infrared Astronomy (SOFIA) Program has overcome many difficult challenges and recently achieved its first light images. To achieve success, SOFIA had to overcome significant deficiencies in fundamental Systems Engineering identified during a major Program restructuring. This presentation will summarize the lessons learn in Systems Engineering on the SOFIA Program. After the Program was reformulated, an initial assessment of Systems Engineering established the scope of the problem and helped to set a list of priorities that needed to be work. A revised Systems Engineering Management Plan (SEMP) was written to address the new Program structure and requirements established in the approved NPR7123.1A. An important result of the "Technical Planning" effort was the decision by the Program and Technical Leadership team to re-phasing the lifecycle into increments. The reformed SOFIA Program Office had to quickly develop and establish several new System Engineering core processes including; Requirements Management, Risk Management, Configuration Management and Data Management. Implementing these processes had to consider the physical and cultural diversity of the SOFIA Program team which includes two Projects spanning two NASA Centers, a major German partnership, and sub-contractors located across the United States and Europe. The SOFIA Program experience represents a creative approach to doing "System Engineering in the middle" while a Program is well established. Many challenges were identified and overcome. The SOFIA example demonstrates it is never too late to benefit from fixing deficiencies in the System Engineering processes.

Ray, Ronald J.↗

Reducing Traffic Congestions by Introducing CACC-Vehicles on a Multi-Lane Highway Using Agent-Based Approach

Traffic congestion is an ongoing problem of great interest to researchers from different areas in academia. With the emerging technology for inter-vehicle communication, vehicles have the ability to exchange information with predecessors by wireless communication. In this paper, we present an agent-based model of traffic congestion and examine the impact of having CACC (Cooperative Adaptive Cruise Control) embedded vehicle(s) on a highway system consisting of 4 traffic lanes without overtaking. In our model, CACC vehicles adapt their acceleration/deceleration according to vehicle-to-vehicle inter-communication. We analyze the average speed of the cars, the shockwaves, and the evolution of traffic congestion throughout the lifecycle of the model. The study identifies how CACC vehicles affect the dynamics of traffic flow on a complex network and reduce the oscillatory behavior (stop and go) resulting from the acceleration/deceleration of the vehicles.

Arnaout, Georges M.↗

Guidance, Navigation, and Control Program

The Rendezvous and Proximity Operations Program (RPOP) is real-time guidance, navigation, and control (GN&C) domain piloting-aid software that provides 3D Orbiter graphics and runs on the Space Shuttle's Criticality-3 Payload and General Support Computer (PGSC) in the crew cockpit. This software provides the crew with Situational Awareness during the rendezvous and proximity operations phases of flight. RPOP can be configured from flight to flight, accounting for mission-specific flight scenarios and target vehicles, via initialization load (I-load) data files. The software provides real-time, automated, closed-loop guidance recommendations and the capability to integrate the crew s manual backup techniques. The software can bring all relative navigation sensor data, including the Orbiter's GPC (general purpose computer) data, into one central application to provide comprehensive situational awareness of the rendezvous and proximity operations trajectory. RPOP also can separately maintain trajectory estimates (past, current, and predicted) based on certain data types and co-plot them, in order to show how the various navigation solutions compare. RPOP s best estimate of the relative trajectory is determined by a relative Kalman filter processing data provided by the sensor suite s most accurate sensor, the trajectory control sensor (TCS). Integrated with the Kalman filter is an algorithm that identifies the reflector that the TCS is tracking. Because RPOP runs on PC laptop computers, the development and certification lifecycles are more agile, flexible, and cheaper than those that govern the Orbiter FSW (flight software) that runs in the GPC. New releases of RPOP can be turned around on a 3- to 6-month template, from new Change Request (CR) to certification, depending on the complexity of the changes.

Hinkel, Heather↗

Changes in Stratiform Clouds of Mesoscale Convective Complex Introduced by Dust Aerosols

Aerosols influence the earth s climate through direct, indirect, and semi-direct effects. There are large uncertainties in quantifying these effects due to limited measurements and observations of aerosol-cloud-precipitation interactions. As a major terrestrial source of atmospheric aerosols, dusts may serve as a significant climate forcing for the changing climate because of its effect on solar and thermal radiation as well as on clouds and precipitation processes. Latest satellites measurements enable us to determine dust aerosol loadings and cloud distributions and can potentially be used to reduce the uncertainties in the estimations of aerosol effects on climate. This study uses sensors on various satellites to investigate the impact of mineral dust on cloud microphysical and precipitation processes in mesoscale convective complex (MCC). A trans-Atlantic dust outbreak of Saharan origin occurring in early March 2004 is considered. For the observed MCCs under a given convective strength, small hydrometeors were found more prevalent in the dusty stratiform regions than in those regions that were dust free. Evidence of abundant cloud ice particles in the dust regions, particularly at altitudes where heterogeneous nucleation of mineral dust prevails, further supports the observed changes of clouds and precipitation. The consequences of the microphysical effects of the dust aerosols were to shift the size spectrum of precipitation-sized hydrometeors from heavy precipitation to light precipitation and ultimately to suppress precipitation and increase the lifecycle of cloud systems, especially over stratiform areas.

Lin, B.↗

Software Development Standard Processes (SDSP)

A JPL-created set of standard processes is to be used throughout the lifecycle of software development. These SDSPs cover a range of activities, from management and engineering activities, to assurance and support activities. These processes must be applied to software tasks per a prescribed set of procedures. JPL s Software Quality Improvement Project is currently working at the behest of the JPL Software Process Owner to ensure that all applicable software tasks follow these procedures. The SDSPs are captured as a set of 22 standards in JPL s software process domain. They were developed in-house at JPL by a number of Subject Matter Experts (SMEs) residing primarily within the Engineering and Science Directorate, but also from the Business Operations Directorate and Safety and Mission Success Directorate. These practices include not only currently performed best practices, but also JPL-desired future practices in key thrust areas like software architecting and software reuse analysis. Additionally, these SDSPs conform to many standards and requirements to which JPL projects are beholden.

Lavin, Milton L.↗

Mission Scenario Development Workbench

The Mission Scenario Development Workbench (MSDW) is a multidisciplinary performance analysis software tool for planning and optimizing space missions. It provides a number of new capabilities that are particularly useful for planning the surface activities on other planets. MSDW enables rapid planning of a space mission and supports flight system and scientific-instrumentation trades. It also provides an estimate of the ability of flight, ground, and science systems to meet high-level mission goals and provides means of evaluating expected mission performance at an early stage of planning in the project life cycle. In MSDW, activity plans and equipment-list spreadsheets are integrated with validated parameterized simulation models of spacecraft systems. In contrast to traditional approaches involving worst-case estimates with large margins, the approach embodied in MSDW affords more flexibility and more credible results early in the lifecycle through the use of validated, variable- fidelity models of spacecraft systems. MSDW is expected to help maximize the scientific return on investment for space missions by understanding early the performance required to have a successful mission while reducing the risk of costly design changes made at late stages in the project life cycle.

Kordon, Mark↗

State Analysis Database Tool

The State Analysis Database Tool software establishes a productive environment for collaboration among software and system engineers engaged in the development of complex interacting systems. The tool embodies State Analysis, a model-based system engineering methodology founded on a state-based control architecture (see figure). A state represents a momentary condition of an evolving system, and a model may describe how a state evolves and is affected by other states. The State Analysis methodology is a process for capturing system and software requirements in the form of explicit models and states, and defining goal-based operational plans consistent with the models. Requirements, models, and operational concerns have traditionally been documented in a variety of system engineering artifacts that address different aspects of a mission s lifecycle. In State Analysis, requirements, models, and operations information are State Analysis artifacts that are consistent and stored in a State Analysis Database. The tool includes a back-end database, a multi-platform front-end client, and Web-based administrative functions. The tool is structured to prompt an engineer to follow the State Analysis methodology, to encourage state discovery and model description, and to make software requirements and operations plans consistent with model descriptions.

Rasmussen, Robert↗

TAMU: A New Space Mission Operations Paradigm

The Transferable, Adaptable, Modular and Upgradeable (TAMU) Flight Production Process (FPP) is a model-centric System of System (SoS) framework which cuts across multiple organizations and their associated facilities, that are, in the most general case, in geographically diverse locations, to develop the architecture and associated workflow processes for a broad range of mission operations. Further, TAMU FPP envisions the simulation, automatic execution and re-planning of orchestrated workflow processes as they become operational. This paper provides the vision for the TAMU FPP paradigm. This includes a complete, coherent technique, process and tool set that result in an infrastructure that can be used for full lifecycle design and decision making during any flight production process. A flight production process is the process of developing all products that are necessary for flight.

Meshkat, Leila↗

Ground Processing Affordability for Space Vehicles

Launch vehicles and most of their payloads spend the majority of their time on the ground. The cost of ground operations is very high. So, why so often is so little attention given to ground processing during development? The current global space industry and economic environment are driving more need for efficiencies to save time and money. Affordability and sustainability are more important now than ever. We can not continue to treat space vehicles as mere science projects. More RLV's (Reusable Launch Vehicles) are being developed for the gains of reusability which are not available for ELV's (Expendable Launch Vehicles). More human-rated vehicles are being developed, with the retirement of the Space Shuttles, and for a new global space race, yet these cost more than the many unmanned vehicles of today. We can learn many lessons on affordability from RLV's. DFO (Design for Operations) considers ground operations during design, development, and manufacturing-before the first flight. This is often minimized for space vehicles, but is very important. Vehicles are designed for launch and mission operations. You will not be able to do it again if it is too slow or costly to get there. Many times, technology changes faster than space products such that what is launched includes outdated features, thus reducing competitiveness. Ground operations must be considered for the full product Lifecycle, from concept to retirement. Once manufactured, launch vehicles along with their payloads and launch systems require a long path of processing before launch. Initial assembly and testing always discover problems to address. A solid integration program is essential to minimize these impacts, as was seen in the Constellation Ares I-X test rocket. For RLV's, landing/recovery and post-flight turnaround activities are performed. Multi-use vehicles require reconfiguration. MRO (Maintenance, Repair, and Overhaul) must be well-planned--- even for the unplanned problems. Defect limits and standard repairs need to be in-place as well as easily added. Many routine inspections and maintenance can be like an aircraft overhaul. Modifications and technology upgrades should be expected. Another factor affecting ground operations efficiency is trending. It is essential for RLV's, and also useful for ELV's which fly the same or similar models again. Good data analysis of technical and processing performance will determine fixes and improvements needed for safety, design, and future processing. Collecting such data on new or low-frequency vehicles is a challenge. Lessons can be learned from the Space Shuttle, or even the Concorde aircraft. For all of the above topics, efficient business systems must be established for comprehensive program management and good throughput. Drawings, specifications, and manuals for an entire launch vehicle are often in different formats from multiple vendors, plus they have proprietary constraints. Nonetheless, the integration team must ensure that all data needed is compatible and visible to each appropriate team member. Ground processing systems for scheduling, tracking, problem resolution, etc. must be well laid-out. The balance between COTS (commercial off the shelf) and custom software is difficult. Multiple customers, vendors, launch sites, and landing sites add to the complexity of efficient IT (Information Technology) tools.

Ingalls, John↗

Integrated Human-Robotic Missions to the Moon and Mars: Mission Operations Design Implications

For most of the history of space exploration, human and robotic programs have been independent, and have responded to distinct requirements. The NASA Vision for Space Exploration calls for the return of humans to the Moon, and the eventual human exploration of Mars; the complexity of this range of missions will require an unprecedented use of automation and robotics in support of human crews. The challenges of human Mars missions, including roundtrip communications time delays of 6 to 40 minutes, interplanetary transit times of many months, and the need to manage lifecycle costs, will require the evolution of a new mission operations paradigm far less dependent on real-time monitoring and response by an Earthbound operations team. Robotic systems and automation will augment human capability, increase human safety by providing means to perform many tasks without requiring immediate human presence, and enable the transfer of traditional mission control tasks from the ground to crews. Developing and validating the new paradigm and its associated infrastructure may place requirements on operations design for nearer-term lunar missions. The authors, representing both the human and robotic mission operations communities, assess human lunar and Mars mission challenges, and consider how human-robot operations may be integrated to enable efficient joint operations, with the eventual emergence of a unified exploration operations culture.

human robotic missions↗

Integrated Procedures for Flight and Ground Operations Using International Standards

Imagine astronauts using the same Interactive Electronic Technical Manuals (IETM's) as the ground personnel who assemble or maintain their flight hardware, and having all of that data interoperable with design, logistics, reliability analysis, and training. Modern international standards and their corresponding COTS tools already used in other industries provide a good foundation for streamlined technical publications in the space industry. These standards cover everything from data exchange to product breakdown structure to business rules flexibility. Full Product Lifecycle Support (PLCS) is supported. The concept is to organize, build once, reuse many ways, and integrate. This should apply to all future and some current launch vehicles, payloads, space stations/habitats, spacecraft, facilities, support equipment, and retrieval ships.

Ingalls, John↗

Engineering the System and Technical Integration

Approximately 80% of the problems encountered in aerospace systems have been due to a breakdown in technical integration and/or systems engineering. One of the major challenges we face in designing, building, and operating space systems is: how is adequate integration achieved for the systems various functions, parts, and infrastructure? This Contractor Report (CR) deals with part of the problem of how we engineer the total system in order to achieve the best balanced design. We will discuss a key aspect of this question - the principle of Technical Integration and its components, along with management and decision making. The CR will first provide an introduction with a discussion of the Challenges in Space System Design and meeting the challenges. Next is an overview of Engineering the System including Technical Integration. Engineering the System is expanded to include key aspects of the Design Process, Lifecycle Considerations, etc. The basic information and figures used in this CR were presented in a NASA training program for Program and Project Managers Development (PPMD) in classes at Georgia Tech and at Marshall Space Flight Center (MSFC). Many of the principles and illustrations are extracted from the courses we teach for MSFC.

Blair, J. C.↗

Morpheus Lander Testing Campaign

NASA s Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing designed to serve as a testbed for advanced spacecraft technologies. The Morpheus vehicle has successfully performed a set of integrated vehicle test flights including hot-fire and tether tests, ultimately culminating in an un-tethered "free-flight" This development and testing campaign was conducted on-site at the Johnson Space Center (JSC), less than one year after project start. Designed, developed, manufactured and operated in-house by engineers at JSC, the Morpheus Project represents an unprecedented departure from recent NASA programs and projects that traditionally require longer development lifecycles and testing at remote, dedicated testing facilities. This paper documents the integrated testing campaign, including descriptions of test types (hot-fire, tether, and free-flight), test objectives, and the infrastructure of JSC testing facilities. A major focus of the paper will be the fast pace of the project, rapid prototyping, frequent testing, and lessons learned from this departure from the traditional engineering development process at NASA s Johnson Space Center.

Hart, Jeremy J.↗

Damage Control Plan for International Space Station Recharge Tank Assembly Composite Overwrapped Pressure Vessel

As NASA has retired the Space Shuttle Program, a new method of transporting compressed gaseous nitrogen and oxygen needed to be created for delivery of these crucial life support resources to the International Space Station (ISS). One of the methods selected by NASA includes the use of highly pressurized, unprotected Recharge Tank Assemblies (RTAs) utilizing Composite Overwrapped Pressure Vessels (COPVs). A COPV consists of a thin liner wrapped with a fiber composite and resin or epoxy. It is typically lighter weight than an all metal pressure vessel of similar volume and therefore provides a higher-efficiency means for gas storage. However COPVs are known to be susceptible to damage resulting from handling, tool drop impacts, or impacts from other objects. As a result, a comprehensive Damage Control Plan has been established to mitigate damage to the RTA COPV throughout its life cycle. The DCP is intended to evaluate and mitigate defined threats during manufacturing, shipping and handling, test, assembly level integration, shipment while pressurized, launch vehicle integration and mission operations by defining credible threats and methods for preventing potential damage while still maintaining the primary goal of resupplying ISS gas resources. A comprehensive threat assessment is performed to identify all threats posed to the COPV during the different phases of its lifecycle. The threat assessment is then used as the basis for creating a series of general inspection, surveillance and reporting requirements which apply across all phases of the COPV's life, targeted requirements only applicable to specific work phases and a series of training courses for both ground personnel and crew aboard the ISS. A particularly important area of emphasis deals with creating DCP requirements for a highly pressurized, large and unprotected RTA COPV for use during Inter Vehicular Activities (IVA) operations in the micro gravity environment while supplying pressurized gas to the ISS for crew life support.

Cook, Anthony J.↗

Software for Remote Monitoring of Space-Station Payloads

Telescience Resource Kit (TReK) is a suite of application programs that enable geographically dispersed users to monitor scientific payloads aboard the International Space Station (ISS). TReK provides local ground support services that can simultaneously receive, process, record, playback, and display data from multiple sources. TReK also provides interfaces to use the remote services provided by the Payload Operations Integration Center which manages all ISS payloads. An application programming interface (API) allows for payload users to gain access to all data processed by TReK and allows payload-specific tools and programs to be built or integrated with TReK. Used in conjunction with other ISS-provided tools, TReK provides the ability to integrate payloads with the operational ground system early in the lifecycle. This reduces the potential for operational problems and provides "cradle-to-grave" end-to-end operations. TReK contains user guides and self-paced tutorials along with training applications to allow the user to become familiar with the system.

Schneider, Michelle↗

A Software Safety Risk Taxonomy for Use in Retrospective Safety Cases

Safety standards contain technical and process-oriented safely requirements. The best time to include these requirements is early in the development lifecycle of the system. When software safety requirements are levied on a legacy system after the fact, a retrospective safety case will need to be constructed for the software in the system. This can be a difficult task because there may be few to no art facts available to show compliance to the software safely requirements. The risks associated with not meeting safely requirements in a legacy safely-critical computer system must be addressed to give confidence for reuse. This paper introduces a proposal for a software safely risk taxonomy for legacy safely-critical computer systems, by specializing the Software Engineering Institute's 'Software Development Risk Taxonomy' with safely elements and attributes.

Hill, Janice L.↗

Human Systems Integration in Practice: Constellation Lessons Learned

NASA's Constellation program provided a unique testbed for Human Systems Integration (HSI) as a fundamental element of the Systems Engineering process. Constellation was the first major program to have HSI mandated by NASA's Human Rating document. Proper HSI is critical to the success of any project that relies on humans to function as operators, maintainers, or controllers of a system. HSI improves mission, system and human performance, significantly reduces lifecycle costs, lowers risk and minimizes re-design. Successful HSI begins with sufficient project schedule dedicated to the generation of human systems requirements, but is by no means solely a requirements management process. A top-down systems engineering process that recognizes throughout the organization, human factors as a technical discipline equal to traditional engineering disciplines with authority for the overall system. This partners with a bottoms-up mechanism for human-centered design and technical issue resolution. The Constellation Human Systems Integration Group (HSIG) was a part of the Systems Engineering and Integration (SE&I) organization within the program office, and existed alongside similar groups such as Flight Performance, Environments & Constraints, and Integrated Loads, Structures and Mechanisms. While the HSIG successfully managed, via influence leadership, a down-and-in Community of Practice to facilitate technical integration and issue resolution, it lacked parallel top-down authority to drive integrated design. This presentation will discuss how HSI was applied to Constellation, the lessons learned and best practices it revealed, and recommendations to future NASA program and project managers. This presentation will discuss how Human Systems Integration (HSI) was applied to NASA's Constellation program, the lessons learned and best practices it revealed, and recommendations to future NASA program and project managers on how to accomplish this critical function.

Zumbado, Jennifer Rochlis↗

Framework for Integrating Science Data Processing Algorithms Into Process Control Systems

A software framework called PCS Task Wrapper is responsible for standardizing the setup, process initiation, execution, and file management tasks surrounding the execution of science data algorithms, which are referred to by NASA as Product Generation Executives (PGEs). PGEs codify a scientific algorithm, some step in the overall scientific process involved in a mission science workflow. The PCS Task Wrapper provides a stable operating environment to the underlying PGE during its execution lifecycle. If the PGE requires a file, or metadata regarding the file, the PCS Task Wrapper is responsible for delivering that information to the PGE in a manner that meets its requirements. If the PGE requires knowledge of upstream or downstream PGEs in a sequence of executions, that information is also made available. Finally, if information regarding disk space, or node information such as CPU availability, etc., is required, the PCS Task Wrapper provides this information to the underlying PGE. After this information is collected, the PGE is executed, and its output Product file and Metadata generation is managed via the PCS Task Wrapper framework. The innovation is responsible for marshalling output Products and Metadata back to a PCS File Management component for use in downstream data processing and pedigree. In support of this, the PCS Task Wrapper leverages the PCS Crawler Framework to ingest (during pipeline processing) the output Product files and Metadata produced by the PGE. The architectural components of the PCS Task Wrapper framework include PGE Task Instance, PGE Config File Builder, Config File Property Adder, Science PGE Config File Writer, and PCS Met file Writer. This innovative framework is really the unifying bridge between the execution of a step in the overall processing pipeline, and the available PCS component services as well as the information that they collectively manage.

Mattmann, Chris A.↗