Results for “building operations” — Page 9

NASA NTRS2012

Re-Engineering the Mission Operations System (MOS) for the Prime and Extended Mission

One of the most challenging tasks in a space science mission is designing the Mission Operations System (MOS). Whereas the focus of the project is getting the spacecraft built and tested for launch, the mission operations engineers must build a system to carry out the science objectives. The completed MOS design is then formally assessed in the many reviews. Once a mission has completed the reviews, the Mission Operation System (MOS) design has been validated to the Functional Requirements and is ready for operations. The design was built based on heritage processes, new technology, and lessons learned from past experience. Furthermore, our operational concepts must be properly mapped to the mission design and science objectives. However, during the course of implementing the science objective in the operations phase after launch, the MOS experiences an evolutional change to adapt for actual performance characteristics. This drives the re-engineering of the MOS, because the MOS includes the flight and ground segments. Using the Spitzer mission as an example we demonstrate how the MOS design evolved for both the prime and extended mission to enhance the overall efficiency for science return. In our re-engineering process, we ensured that no requirements were violated or mission objectives compromised. In most cases, optimized performance across the MOS, including gains in science return as well as savings in the budget profile was achieved. Finally, we suggest a need to better categorize the Operations Phase (Phase E) in the NASA Life-Cycle Phases of Formulation and Implementation

Extended Mission↗

NASA NTRS2005

Introduction to System Health Engineering and Management in Aerospace

This paper provides a technical overview of Integrated System Health Engineering and Management (ISHEM). We define ISHEM as "the paper provides a techniques, and technologies used to design, analyze, build, verify, and operate a system to prevent faults and/or minimize their effects." This includes design and manufacturing techniques as well operational and managerial methods. ISHEM is not a "purely technical issue" as it also involves and must account for organizational, communicative, and cognitive f&ms of humans as social beings and as individuals. Thus the paper will discuss in more detail why all of these elements, h m the technical to the cognitive and social, are necessary to build dependable human-machine systems. The paper outlines a functional homework and architecture for ISHEM operations, describes the processes needed to implement ISHEM in the system life-cycle, and provides a theoretical framework to understand the relationship between the different aspects of the discipline. It then derives from these and the social and cognitive bases a set of design and operational principles for ISHEM.

Johnson, Stephen B.↗

NASA NTRS2018

Advantages of a Modular Mars Surface Habitat Approach

Early crewed Mars mission concepts developed by the National Aeronautics and Space Administration (NASA) assumed a single, large habitat would house six crew members for a 500-day Mars surface stay. At the end of the first mission, all surface equipment, including the habitat, -would be abandoned and the process would be repeated at a different Martian landing site. This work was documented in a series of NASA publications culminating with the Mars Design Reference Mission 5.0 (NASA-SP-2009-566). The Evolvable Mars Campaign (EMC) explored whether re-using surface equipment at a single landing site could be more affordable than the Apollo-style explore-abandon-repeat mission cadence. Initial EMC assumptions preserved the single, monolithic habitat, the only difference being a new requirement to reuse the surface habitat for multiple expedition crews. A trade study comparing a single large habitat versus smaller, modular habitats leaned towards the monolithic approach as more mass-efficient. More recent work has focused on the operational aspects of building up Mars surface infrastructure over multiple missions, and has identified compelling advantages of the modular approach that should be considered before making a final decision. This paper explores Mars surface mission operational concepts and integrated system analysis, and presents an argument for the modular habitat approach.

Rucker, Michelle A.↗

NASA NTRS2018

Advantages of a Modular Mars Surface Habitat Approach

Early crewed Mars mission concepts developed by the National Aeronautics and Space Administration (NASA) assumed a single, large habitat would house six crew members for a 500-day Mars surface stay. At the end of the first mission, all surface equipment-including the habitat-would be abandoned and the process would be repeated at a different Martian landing site. This work was documented in a series of NASA publications culminating with the Mars Design Reference Architecture 5.0. More recent work, dubbed the Evolvable Mars Campaign (EMC), explored whether re-using surface equipment at a single landing site could be more affordable than the Apollo-style explore-abandon-repeat mission cadence. Initial EMC assumptions preserved the single, monolithic habitat-the only difference being a new requirement to reuse the surface habitat for multiple expedition crews. A trade study comparing a single large habitat versus smaller, modular habitats leaned towards the monolithic approach as more mass-efficient. More recent work has focused on the operational aspects of building up Mars surface infrastructure over multiple missions, and has identified compelling advantages of a modular approach that should be considered before making a final decision. This paper explores Mars surface mission operational concepts and integrated system analysis, and presents an argument for the modular habitat approach.

Rucker, Michelle A.↗

NASA NTRS2018

Advantages of a Modular Mars Surface Habitat Approach

Early crewed Mars mission concepts developed by the National Aeronautics and Space Administration (NASA) assumed a single, large habitat would house six crew members for a 500-day Mars surface stay. At the end of the first mission, all surface equipment?including the habitat--would be abandoned and the process would be repeated at a different Martian landing site. This work was documented in a series of NASA publications culminating with the Mars Design Reference Mission 5.0 (NASA-SP-2009-566). The Evolvable Mars Campaign (EMC) explored whether re-using surface equipment at a single landing site could be more affordable than the Apollo-style explore-abandon-repeat mission cadence. Initial EMC assumptions preserved the single, monolithic habitat?the only difference being a new requirement to reuse the surface habitat for multiple expedition crews. A trade study comparing a single large habitat versus smaller, modular habitats leaned towards the monolithic approach as more mass-efficient. More recent work has focused on the operational aspects of building up Mars surface infrastructure over multiple missions, and has identified compelling advantages of the modular approach that should be considered before making a final decision. This paper explores Mars surface mission operational concepts and integrated system analysis, and presents an argument for the modular habitat approach.

Rucker, Michelle↗

NASA NTRS1988

A Multiprocessor Operating System Simulator

This paper describes a multiprocessor operating system simulator that was developed by the authors in the Fall semester of 1987. The simulator was built in response to the need to provide students with an environment in which to build and test operating system concepts as part of the coursework of a third-year undergraduate operating systems course. Written in C++, the simulator uses the co-routine style task package that is distributed with the AT&T C++ Translator to provide a hierarchy of classes that represents a broad range of operating system software and hardware components. The class hierarchy closely follows that of the 'Choices' family of operating systems for loosely- and tightly-coupled multiprocessors. During an operating system course, these classes are refined and specialized by students in homework assignments to facilitate experimentation with different aspects of operating system design and policy decisions. The current implementation runs on the IBM RT PC under 4.3bsd UNIX.

Johnston, Gary M.↗

NASA NTRSDate not supplied

Simplified Vehicle Control Concept for a Lift Plus Cruise eVTOL Vehicle

Electric Vertical Takeoff and Landing (eVTOL) vehicles have the potential to enable cost effective Urban Air Mobility (UAM) applications. These concepts may also pose several challenging handling and control problems, which must be addressed prior to safe and reliable urban operations. This paper investigates a simplified vehicle control concept that is designed to address some of these challenges for a conceptual Lift Plus Cruise vehicle designed by NASA’s Revolutionary Vertical Lift Technology (RVLT) project. The command and control architecture for this concept is presented along with preliminary findings. Initial results explore the vehicle performance in an approach to hover transition scenario, designed to explore the challenge of dissipating energy across all flight regimes. Operational concepts with varying aggressiveness are evaluated through changing glideslope and deceleration rates. Preliminary results show that the simplified control concept is effective over these operational conditions, with control strategies and envelope protection limits able to maintain control though aggressive operations despite saturation at steeper slopes with higher deceleration rates. Final results will show piloted simulation evaluations in the the Aerospace Cognitive Engineering Lab – Rapid Automation Test Environment (ACEL-RATE) laboratory at NASA Ames Research Center. The planned tests will build on these operations with additional test cases exploring variations in wind conditions as well as transition-to-hover automation strategies and display information.

simplified vehicle control↗

NASA NTRS1993

PERTS: A Prototyping Environment for Real-Time Systems

PERTS is a prototyping environment for real-time systems. It is being built incrementally and will contain basic building blocks of operating systems for time-critical applications, tools, and performance models for the analysis, evaluation and measurement of real-time systems and a simulation/emulation environment. It is designed to support the use and evaluation of new design approaches, experimentations with alternative system building blocks, and the analysis and performance profiling of prototype real-time systems.

Liu, Jane W. S.↗

NASA NTRSDate not supplied

Reports of Resilient Performance: Investigating Operators' Descriptions of Safety-producing Behaviors in the Aviation Safety Reporting System

While many existing taxonomies and frameworks provide a common vocabulary for describing how human operators fail in the context of sociotechnical systems, at present, there is no common vocabulary to describe how humans succeed. Such a framework would facilitate systematically collecting and analyzing data on how human performance can produce safety, not just how it can reduce safety. One potentially rich source of currently available information for exploring desired performance is the reports submitted to NASA’s Aviation Safety Reporting System (ASRS). These de-identified, confidential, and voluntary narrative reports are submitted by pilots, controllers, ground operators, and others within aviation operations. While these reports are primarily submitted to describe safety risks, incidents, and problems, they also often describe how those risks were mitigated, and provide a window into aspects of everyday work in aviation. These reports can be searched in a variety of ways. This paper describes methods for systematically examining ASRS narratives to understand how operators talk about their own resilient behaviors during adverse safety conditions and events. Guided by Erik Hollnagel’s Resilience Assessment Grid framework (i.e., anticipate, monitor, respond, learn), various approaches and tools for such inquiries are described. The approach, process, challenges, and suggestions to building an operator-based description of resilient performance are discussed, and tools to facilitate data analysis to maximize learning from these reports are described.

ASRS narratives↗

NASA NTRS2007

50 Years of Electronic Check Out and Launch Systems at Kennedy Space Center

When NASA was created in 1958 one of the elements incorporated into this new agency was the Army Ballistic Missile Agency (ABMA) in Huntsville, AL and its subordinate Missile Firing Laboratory (MFL) in Cape Canaveral. Under NASA, the MFL became the Launch Operations Directorate of the George C. Marshall Space Flight Center in Huntsville, but expanding operations in the build up to Apollo dictated that it be given the status of a full fledged Center in July, 1 962[ 1]. The next year it was renamed the John F. Kennedy Space Center (KS C) after the president whose vision transformed its first decade of operation. The ABMA was under the technical leadership of Dr. Werner Von Braun. The MEL was run by his deputy Dr. Kurt Debus, an electrical engineer whose experience in the field began in the early days of V-2 testing in war time Germany. In 1952 a group led by Debus arrived in Cape Canaveral to begin test launches of the new Redstone missile [2]. During the 50's, The MFL built several launch complexes and tested the Redstone, Jupiter and Jupiter C missiles. This small experienced team of engineers and technicians formed the seed from which has grown the KSC team of today. This article briefly reviews the evolution of the KSC electronic technologies for integration, check-out and launch of space vehicles and payloads during NASA's first 50 years.

Starr, Stanley O.↗

NASA NTRS1978

Noise-Induced Building Vibrations Caused by Concorde and Conventional Aircraft Operations at Dulles and Kennedy International Airports

Outdoor and indoor noise levels resulting from aircraft flyovers and certain nonaircraft events were recorded, as were the associated vibration levels in the walls, windows, and floors at building test sites. In addition, limited subjective tests were conducted to examine the human detection and annoyance thresholds for building vibration and rattle caused by aircraft noise. Representative peak levels of aircraft noise-induced building vibrations are reported and comparisons are made with structural damage criteria and with vibration levels induced by common domestic events. In addition, results of a pilot study are reported which indicate the human detection threshold for noise-induced floor vibrations.

Mayes, W. H.↗

NASA NTRS2014

Renewable Energy at NASA's Johnson Space Center

NASA's Johnson Space Center has implemented a great number of renewable energy systems. Renewable energy systems are necessary to research and implement if we humans are expected to continue to grow and thrive on this planet. These systems generate energy using renewable sources - water, wind, sun - things that we will not run out of. Johnson Space Center is helping to pave the way by installing and studying various renewable energy systems. The objective of this report will be to examine the completed renewable energy projects at NASA's Johnson Space Center for a time span of ten years, beginning in 2003 and ending in early 2014. This report will analyze the success of each project based on actual vs. projected savings and actual vs. projected efficiency. Additionally, both positive and negative experiences are documented so that lessons may be learned from past experiences. NASA is incorporating renewable energy wherever it can, including into buildings. According to the 2012 JSC Annual Sustainability Report, there are 321,660 square feet of green building space on JSC's campus. The two projects discussed here are major contributors to that statistic. These buildings were designed to meet various Leadership in Energy and Environmental Design (LEED) Certification criteria. LEED Certified buildings use 30 to 50 percent less energy and water compared to non-LEED buildings. The objectives of this project were to examine data from the renewable energy systems in two of the green buildings onsite - Building 12 and Building 20. In Building 12, data was examined from the solar photovoltaic arrays. In Building 20, data was examined from the solar water heater system. By examining the data from the two buildings, it could be determined if the renewable energy systems are operating efficiently. Objectives In Building 12, the data from the solar photovoltaic arrays shows that the system is continuously collecting energy from the sun, as shown by the graph below. Building 12 has two solar inverters, located on the second floor, that collected the data from the solar photovoltaic arrays. The data displayed here is the total energy produced by the system. These are cumulative amounts, so the last point on the graph shows all of the energy collected from the system since the start of its operation. The data shown here was manually collected from the solar inverters. However, the data is also automatically recorded through EBI. Through analysis of both sets of data it was determined that the EBI data was faulty. For example, from the manually collected data it can be determined that a total of 73 kWh of energy was collected between the dates of 1/16/2014 – 1/22/2014. The EBI data reports that approximately 17800 kWh of energy was collected during the same time frame. Not only does this exceed the time frame examined, but it also exceeds the total energy collected from the start of collection as recorded from the inverters. This leads to the belief that there is a malfunction with the automatic recording of the energy. In Building 20, data was examined from the solar water heater dating back many months and found that the pump for the solar water heater system was not operating properly, as exhibited in the graph shown below. The pump operates on a solar energy system, meaning that it collects energy throughout the day from the sun. Because of this, the system would stop operating shortly after the sun set because of a lack of sunlight. At that point, the graph should show a zero flow rate, but as exhibited in the graph below, that is not the case. It is clearly shown that the pump is continuously operating, even during the night. It was also observed that the majority of the time the pump would not turn on at all, despite good weather conditions. This led to the conclusion that the pump is malfunctioning, and needs to be examined and fixed.

McDowall, Lindsay↗

NASA NTRS1988

A support architecture for reliable distributed computing systems

The Clouds project is well underway to its goal of building a unified distributed operating system supporting the object model. The operating system design uses the object concept of structuring software at all levels of the system. The basic operating system was developed and work is under progress to build a usable system.

Dasgupta, Partha↗

NASA NTRSDate not supplied

Artemis Innovative Assembly and Integration Operations of the Launch Abort Systemat KSC

This paper describes the Artemis program assembly and integration approach that enables affordable and low risk processing operations for the Launch Abort System at KSC. NASA is currently developing the Artemis 1 spacecraft to meet the test objectives of an uncrewed orbital mission to the moon and return to earth in 2021. The Artemis Orion spacecraft consists of a Crew Module (CM), a Service Module (SM), and a Launch Abort System (LAS) to safely transport a crew of 4 to the moon and return to earth. The LAS enables the CM to have an abort capability for the crew during the launch phase of the mission from the launch pad throughout the ascent phase. The LAS includes motor elements for abort, attitude control, and stage separation is assembled at the Launch Abort System Facility (LASF) adjacent to the CM/SM (CSM) assembly operations in the Neil Armstrong Operations and Checkout Building (O&C) at KSC. The LAS integration to the CSM is completed in the LASF and the completed Artemis spacecraft is integrated to the Space Launch System (SLS) in the Vehicle Assembly Building (VAB) at KSC. A significant LAS development flight test milestone was recently completed in 2019 for the Ascent Abort (AA-2) flight test at Cape Canaveral Air Force Station where a high-altitude abort test was successfully achieved using a Peacekeeper booster stage exercising all of the LAS systems including propulsion, avionics, and pyrotechnics demonstrating he LAS readiness for crewed flight. The first operational flight of the LAS will be for the Artemis 2 mission which is the first crewed mission for the Orion program planned in 2023.

William J Koenig↗

NASA NTRSDate not supplied

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

NASA NTRSDate not supplied

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

NASA NTRS1994

Formal semantics for a subset of VHDL and its use in analysis of the FTPP scoreboard circuit

In the first part of the report, we give a detailed description of an operational semantics for a large subset of VHDL, the VHSIC Hardware Description Language. The semantics is written in the functional language Caliban, similar to Haskell, used by the theorem prover Clio. We also describe a translator from VHDL into Caliban semantics and give some examples of its use. In the second part of the report, we describe our experience in using the VHDL semantics to try to verify a large VHDL design. We were not able to complete the verification due to certain complexities of VHDL which we discuss. We propose a VHDL verification method that addresses the problems we encountered but which builds on the operational semantics described in the first part of the report.

Bickford, Mark↗

NASA NTRS2010

Using Web 2.0 Techniques in NASA's Ares Engineering Operations Network (AEON) Environment - First Impressions

The Mission Operations Laboratory (MOL) at Marshall Space Flight Center (MSFC) is responsible for Engineering Support capability for NASA s Ares rocket development and operations. In pursuit of this, MOL is building the Ares Engineering and Operations Network (AEON), a web-based portal to support and simplify two critical activities: Access and analyze Ares manufacturing, test, and flight performance data, with access to Shuttle data for comparison Establish and maintain collaborative communities within the Ares teams/subteams and with other projects, e.g., Space Shuttle, International Space Station (ISS). AEON seeks to provide a seamless interface to a) locally developed engineering applications and b) a Commercial-Off-The-Shelf (COTS) collaborative environment that includes Web 2.0 capabilities, e.g., blogging, wikis, and social networking. This paper discusses how Web 2.0 might be applied to the typically conservative engineering support arena, based on feedback from Integration, Verification, and Validation (IV&V) testing and on searching for their use in similar environments.

Scott, David W.↗