SEARCH · Search NASA

Results for “Ground Operational Support System”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 307 records · Page 17

All sources NASA NTRS DOE OSTI

NASA NTRS2014

Failure Investigation of WB-57 Aircraft Engine Cowling

The NASA Johnson Space Center (JSC) in Houston, Texas is the home of the NASA WB-57 High Altitude Research Program. Three fully operational WB-57 aircraft are based near JSC at Ellington Field. The aircraft have been flying research missions since the early 1960's, and continue to be an asset to the scientific community with professional, reliable, customer-oriented service designed to meet all scientific objectives. The NASA WB-57 Program provides unique, high-altitude airborne platforms to US Government agencies, academic institutions, and commercial customers in order to support scientific research and advanced technology development and testing at locations around the world. Mission examples include atmospheric and earth science, ground mapping, cosmic dust collection, rocket launch support, and test bed operations for future airborne or spaceborne systems. During the return from a 6 hour flight, at 30,000 feet, in the clean configuration, traveling at 175 knots indicated airspeed, in un-accelerated flight with the auto pilot engaged, in calm air, the 2-man crew heard a mechanical bang and felt a slight shudder followed by a few seconds of high frequency vibration. The crew did not notice any other abnormalities leading up to, or for the remaining 1 hour of flight and made an uneventful landing. Upon taxi into the chocks, the recovery ground crew noticed the high frequency long wire antenna had become disconnected from the vertical stabilizer and was trailing over the left inboard wing, and that the left engine upper center removable cowling panel was missing, with noticeable damage to the left engine inboard cowling fixed structure. The missing cowling panel was never recovered. Each engine cowling panel is attached to the engine nacelle using six bushings made of 17-4 PH steel. The cylinder portions of four of the six bushings were found still attached to the aircraft (Fig 1). The other two bushings were lost with the panel. The other four bushings exhibited ratchet marks (multiple fatigue origins) which initiated in the sharp radius of the flange/cylinder fillet and were observed 300 degrees around the flange perimeter (Fig 2-3). Low stress, high cycle fatigue (HCF) was observed on the fracture surfaces of all four bushings (Fig 4). To improve the cowling panel joint design and enable return to flight, new cowling bushings with thicker flanges and a larger machined flange/cylinder fillet radius were installed on all cowling panels. In addition, a spacer was added to the joint to achieve the proper stack tolerance. Finally, a time change requirement for all cowling bushings was instituted.

Martinez, J. E.↗

NASA NTRS1978

An Induced Environment Contamination Monitor for the Space Shuttle

The Induced Environment Contamination Monitor (IECM), a set of ten instruments integrated into a self-contained unit and scheduled to fly on shuttle Orbital Flight Tests 1 through 6 and on Spacelabs 1 and 2, is described. The IECM is designed to measure the actual environment to determine whether the strict controls placed on the shuttle system have solved the contamination problem. Measurements are taken during prelaunch, ascent, on-orbit, descent, and postlanding. The on-orbit measurements are molecular return flux, background spectral intensity, molecular deposition, and optical surface effects. During the other mission phases dew point, humidity, aerosol content, and trace gas are measured as well as optical surface effects and molecular deposition. The IECM systems and thermal design are discussed. Preflight and ground operations are presented together with associated ground support equipment. Flight operations and data reduction plans are given.

Miller, E. R.↗

NASA NTRS1980

Technology requirements for future Earth-to-geosynchronous orbit transportation systems. Volume 2: Technical results

Technologies either critical to performance of offering cost advantages compared to the investment required to bring them to usable confidence levels are identified. A total transportation system is used as an evaluation yardstick. Vehicles included in the system are a single stage to orbit launch vehicle used in a priority cargo role, a matching orbit transfer vehicle, a heavy lift launch vehicle with a low Earth orbit delivery capability of 226, 575 kg, and a matching solar electric cargo orbit transfer vehicle. The system and its reference technology level are consistent with an initial operational capability in 1990. The 15 year mission scenario is based on early space industrialization leading to the deployment of large systems such as power satellites. Life cycle cost benefits in discounted and undiscounted dollars for each vehicle, technology advancement, and the integrated transportation system are calculated. A preliminary functional analysis was made of the operational support requirements for ground based and space based chemical propulsion orbit transfer vehicles.

Caluori, V. A.↗

NASA NTRS1988

System security in the space flight operations center

The Space Flight Operations Center is a networked system of workstation-class computers that will provide ground support for NASA's next generation of deep-space missions. The author recounts the development of the SFOC system security policy and discusses the various management and technology issues involved. Particular attention is given to risk assessment, security plan development, security implications of design requirements, automatic safeguards, and procedural safeguards.

Wagner, David A.↗

NASA NTRS1990

NSTS operations utilization directorate

A basic understanding is provided of the National Space Transportation System payload processing operations performed at NASA-Kennedy. The payload facilities, support services, and ground support equipment used to support that process are described.

Morian, John↗

NASA NTRS1994

Earth Observing System (EOS) Communication (Ecom) Modeling, Analysis, and Testbed (EMAT) activiy

This paper describes the Earth Observing System (EOS) Communication (Ecom) Modeling, Analysis, and Testbed (EMAT) activity performed by Code 540 in support of the Ecom project. Ecom is the ground-to-ground data transport system for operational EOS traffic. The National Aeronautic and Space Administration (NASA) Communications (Nascom) Division, Code 540, is responsible for implementing Ecom. Ecom interfaces with various systems to transport EOS forward link commands, return link telemetry, and science payload data. To understand the complexities surrounding the design and implementation of Ecom, it is necessary that sufficient testbedding, modeling, and analysis be conducted prior to the design phase. These activities, when grouped, are referred to as the EMAT activity. This paper describes work accomplished to date in each of the three major EMAT activities: modeling, analysis, and testbedding.

Desai, Vishal↗

NASA NTRS1997

Ground Taxi Navigation Problems and Training Solutions

Adverse weather conditions can put considerable strain on the National Airspace System. Even small decreases in visibility on the airport surface can create delays, hinder safe movement and lead to errors. Studies of Aviation Safety Reporting System (ASRS) surface movement incidents support the need for technologies and procedures to improve ground operations in low-visibility conditions. This study examined 139 ASRS reports of low-visibility surface movement incidents at 10 major U.S. airports. Errors were characterized in terms of incident type, contributing factors and consequences. The incidents in the present sample were comprised of runway transgressions, taxiway excursions and ground conflicts. The primary contributing factors were Airport Layout and Markings, Communication and Distraction. In half the incidents the controller issued a new clearance or the flight crew took an evasive action and in the remaining half, no recovery attempt was made because the error was detected after the fact. By gaining a better understanding the factors that affect crew navigation in low visibility and the types of errors that are likely to occur, it will be possible to develop more robust technologies to aid pilots in the ground taxi task. Implications for crew training and procedure development for low-visibility ground taxi are also discussed.

Quinn, Cheryl↗

NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗

NASA NTRSDate not supplied

Risk-Reduction Autonomy Implementation to Enable NASA Artemis Missions

To achieve NASA’s Artemis program mission objectives a high level of autonomy and ubiquitous autonomy throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and concepts of operations for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, concepts of operations, and interface control documents, in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module(i.e. ECLSS).A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM)to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design –GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1)to implement autonomy at the VSM, MSM, and SM levels;(2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1)Orion as visiting vehicle registers with VSM;(2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) standalone demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.

Autonomous Systems↗

NASA NTRSDate not supplied

Risk-Reduction Autonomy Implementation to Enable NASA Artemis Missions

To achieve NASA’s Artemis program mission objectives a high level of autonomy that is ubiquitous throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and Concepts of Operations (ConOps) for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, ConOps, and interface control documents (ICDs), in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module (i.e. ECLSS). A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM) to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design – GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1) to implement autonomy at the VSM, MSM, and SM levels; (2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with the VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1) Orion as visiting vehicle registers with VSM; (2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.

Fernando Figueroa↗

NASA NTRS1972

Tracking and data relay satellite system configuration and tradeoff study. Volume 7: Telecommunications system summary, part 1

The baseline Tracking and Data Relay Satellite telecommunication system is described. The configurations of the user spacecraft terminal and the ground based terminal are illustrated. The system service and performance summary is developed to show the link support, modes of operation, and link performance to the low data rate and medium data rate user spacecraft. The link budget calculation is included to show a typical computation for each space-to-space and space-to-ground link with the assumptions used in each calculation.

Hill, T. E.↗

NASA NTRS1993

System architecture for asynchronous multi-processor robotic control system

The architecture for the Modular Telerobot Task Execution System (MOTES) as implemented in the Supervisory Telerobotics (STELER) Laboratory is described. MOTES is the software component of the remote site of a local-remote telerobotic system which is being developed for NASA for space applications, in particular Space Station Freedom applications. The system is being developed to provide control and supervised autonomous control to support both space based operation and ground-remote control with time delay. The local-remote architecture places task planning responsibilities at the local site and task execution responsibilities at the remote site. This separation allows the remote site to be designed to optimize task execution capability within a limited computational environment such as is expected in flight systems. The local site task planning system could be placed on the ground where few computational limitations are expected. MOTES is written in the Ada programming language for a multiprocessor environment.

Steele, Robert D.↗

NASA NTRS2014

Supporting Multiple Programs and Projects at NASA's Kennedy Space Center

With the conclusion of the shuttle program in 2011, the National Aeronautics and Space Administration (NASA) had found itself at a crossroads for finding transportation of United States astronauts and experiments to space. The agency would eventually hand off the taxiing of American astronauts to the International Space Station (ISS) that orbits in Low Earth Orbit (LEO) about 210 miles above the earth under the requirements of the Commercial Crew Program (CCP). By privatizing the round trip journey from Earth to the ISS, the space agency has been given the additional time to focus funding and resources to projects that operate beyond LEO; however, adding even more stress to the agency, the premature cancellation of the program that would succeed the Shuttle Program - The Constellation Program (CxP) -it would inevitably delay the goal to travel beyond LEO for a number of years. Enter the Space Launch System (SLS) and the Orion Multipurpose Crew Vehicle (MPCV). Currently, the SLS is under development at NASA's Marshall Spaceflight Center in Huntsville, Alabama, while the Orion Capsule, built by government contractor Lockheed Martin Corporation, has been assembled and is currently under testing at the Kennedy Space Center (KSC) in Florida. In its current vision, SLS will take Orion and its crew to an asteroid that had been captured in an earlier mission in lunar orbit. Additionally, this vehicle and its configuration is NASA's transportation to Mars. Engineers at the Kennedy Space Center are currently working to test the ground systems that will facilitate the launch of Orion and the SLS within its Ground Services Development and Operations (GSDO) Program. Firing Room 1 in the Launch Control Center (LCC) has been refurbished and outfitted to support the SLS Program. In addition, the Spaceport Command and Control System (SCCS) is the underlying control system for monitoring and launching manned launch vehicles. As NASA finds itself at a junction, so does all of its associated centers across the US. KSC has found itself at the blunt end of change as the entire center has transitioned from an operations mindset to a development mentality. The author of this paper has had the fortunate privilege and opportunity to be part of a transforming NASA during the fall months of 2014. The following is a high level account of projects that he had the chance to work on including the Spaceport Command and Control System, the Advanced Ground System and Maintenance Program Project, Customer Avionics Development & Analysis (CAIDA) Lab and Swamp Works.

Advanced Ground System Maintenance↗

NASA NTRS1992

Communications support for lunar missions using the TDRS II system

For several years NASA has been performing systems engineering analysis for lunar exploration scenarios with studies focused mainly on lunar communications, data systems and operations. Two basic earth-region communications architectures have been seriously considered, ground terminal architectures such as the deep space network (DSN) and geosynchronous relay satellites such as the tracking and data relay satellite II (TDRS II). An overview of TDRS II is given and lunar coverage, data rate capability, impacts to ground based elements, availability and operational scenarios are discussed. Development of the system is scheduled to begin soon and TDRS II can provide substantial support to early lunar missions without modification. Coverage and data rates are adequate and FLO missions can be supported. With enhancement nearly continuous coverage can be provided. TDRS II is a viable architecture and low cost option and should be considered as an alternative to the currently baselined DSN for precursor and possibly FLO missions.

Todd, Jacqueline↗

NASA NTRS2013

Master Console System Monitoring and Control Development

The Master Console internship during the summer of 2013 involved the development of firing room displays and support applications at the John F. Kennedy Space Center (KSC). This position was with the Master Console Product Group (MCPG) on the Launch Control System (LCS) project. This project is responsible for the System Monitoring and Control (SMC) and Record and Retrieval (R&R) of launch operations data. The Master Console is responsible for: loading the correct software into each of the remaining consoles in the firing room, connecting the proper data paths to and from the launch vehicle and all ground support equipment, and initializing the entire firing room system to begin processing. During my internship, I created control scripts using the Application Control Language (ACL) to analyze the health and status of Kennedy Ground Control System (KGCS) programmable logic controllers (PLCs). This application provides a system health and status display I created with summarized data for use by Master Console Operators (MCO) to monitor and verify the integrity of KGCS subsystems.

Brooks, Russell A.↗

NASA NTRS2002

NASA 2nd Generation RLV Program Introduction, Status and Future Plans

The Space Launch Initiative (SLI), managed by the Second Generation Reusable Launch Vehicle (2ndGen RLV) Program, was established to examine the possibility of revolutionizing space launch capabilities, define conceptual architectures, and concurrently identify the advanced technologies required to support a next-generation system. Initial Program funds have been allocated to design, evaluate, and formulate realistic plans leading to a 2nd Gen RLV full-scale development (FSD) decision by 2006. Program goals are to reduce both risk and cost for accessing the limitless opportunities afforded outside Earth's atmosphere fo civil, defense, and commercial enterprises. A 2nd Gen RLV architecture includes a reusable Earth-to-orbit launch vehicle, an on-orbit transport and return vehicle, ground and flight operations, mission planning, and both on-orbit and on-the-ground support infrastructures All segments of the architecture must advance in step with development of the RLV if a next-generation system is to be fully operational early next decade. However, experience shows that propulsion is the single largest contributor to unreliability during ascent, requires the largest expenditure of time for maintenance, and takes a long time to develop; therefore, propulsion is the key to meeting safety, reliability, and cost goals. For these reasons, propulsion is SLI's top technology investment area.

Dumbacher, Dan L.↗

NASA NTRS2004

Telescience Resource Kit Software Capabilities and Future Enhancements

The Telescience Resource Kit (TReK) is a suite of PC-based software applications that can be used to monitor and control a payload on board the International Space Station (ISS). This software provides a way for payload users to operate their payloads from their home sites. It can be used by an individual or a team of people. TReK provides both local ground support system services and an interface to utilize remote services provided by the Payload Operations Integration Center (POIC). by the POIC and to perform local data functions such as processing the data, storing it in local files, and forwarding it to other computer systems. TReK can also be used to build, send, and track payload commands. In addition to these features, work is in progress to add a new command management capability. This capability will provide a way to manage a multi- platform command environment that can include geographically distributed computers. This is intended to help those teams that need to manage a shared on-board resource such as a facility class payload. The environment can be configured such that one individual can manage all the command activities associated with that payload. This paper will provide a summary of existing TReK capabilities and a description of the new command management capability. For example, 7'ReK can be used to receive payload data distributed

Schneider, Michelle↗

NASA NTRSDate not supplied

Custom Integration of Multiple Medical Functionalities

INTRODUCTION: Previous spaceflight experience and results from probabilistic risk assessment of spaceflight medical risk have highlighted the need for vital sign measurements, medical scopes, and clinical imaging tools for managing medical conditions during spaceflight. The Human Research Program’s Exploration Medical Capability (ExMC) Element and the Mars Campaign Office’s Exploration Medical Integrated Product Team (XMIPT) have performed ground-based evaluations of two Commercial-off-the-Shelf (COTS) Multi-functional Integrated Medical (MIM) devices, which integrate various medical capabilities together in one device. The key findings from these evaluations are presented in a complementary presentation, leaving this presentation to focus on forward recommendations for customized integration of multiple medical functionalities. KEY COMPONENTS: The key features of a custom integration of multiple medical functionalities includes devices and capabilities that optimally reduce medical risk. The COTS MIM devices incorporated functionality for best supporting Earth-based, emergency, pre-hospital care. Our custom integration will use probabilistic risk assessment tools, such as the Medical Extensible Dynamic Probabilistic Risk Assessment Tool (MEDPRAT), to determine the optimal functionality to include based on medical risk minimization. An additional feature of custom integration includes the ability to adapt to different requirements within different vehicles and/or missions. The COTS MIM devices store data in patient specific records, however, the format of the records is not modifiable, and data are not easily transferred from the MIM device to a central data architecture outside of the manufacturer’s established system. Our concept for custom integration will use devices that have an open application programming interface, which can easily connect to independent data architectures and third-party visualization software. The ultrasound capabilities included within the COTS MIM devices did not satisfy many of the Artemis Research and Operations Working Group’s ultrasound functional needs, and therefore, incorporation of higher quality ultrasound capabilities within a customized integration will be beneficial. The COTS MIM devices included minimal procedural guidance and clinical decision support tools. Supplemental tools of this type would need to be supplied along with the COTS MIM devices if they were to be used operationally, so another advantage of customization is the ability to integrate these support tools along with the medical functionality, for a more streamlined user experience. CONCLUSION: Investigation of a customized integration of medical functionality provides a method for further understanding the needs of a long-term exploration spaceflight medical system. The crew members of these exploration missions will need to operate more and more independently from Earth-based ground support. Therefore, having an optimized, streamlined medical system, which contains the functionality and supporting information needed, while remaining within mission and vehicle constraints, will help to maintain crew health and performance, which is necessary for achieving high levels of mission success.

B E Lewandowski↗