Search NASA⌕ Search

SEARCH · Search NASA

Results for “Interoperability”

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 721 records · Page 40

The Trajectory Synthesizer Generalized Profile Interface

The Trajectory Synthesizer is a software program that generates aircraft predictions for Air Traffic Management decision support tools. The Trajectory Synthesizer being used by researchers at NASA Ames Research Center was restricted in the number of trajectory types that could be generated. This limitation was not sufficient to support the rapidly changing Air Traffic Management research requirements. The Generalized Profile Interface was developed to address this issue. It provides a flexible approach to describe the constraints applied to trajectory generation and may provide a method for interoperability between trajectory generators. It also supports the request and generation of new types of trajectory profiles not possible with the previous interface to the Trajectory Synthesizer. Other enhancements allow the Trajectory Synthesizer to meet the current and future needs of Air Traffic Management research.

Lee, Alan G.↗

Reinventing User Applications for Mission Control

In 2006, NASA Ames Research Center's (ARC) Intelligent Systems Division, and NASA Johnson Space Centers (JSC) Mission Operations Directorate (MOD) began a collaboration to move user applications for JSC's mission control center to a new software architecture, intended to replace the existing user applications being used for the Space Shuttle and the International Space Station. It must also carry NASA/JSC mission operations forward to the future, meeting the needs for NASA's exploration programs beyond low Earth orbit. Key requirements for the new architecture, called Mission Control Technologies (MCT) are that end users must be able to compose and build their own software displays without the need for programming, or direct support and approval from a platform services organization. Developers must be able to build MCT components using industry standard languages and tools. Each component of MCT must be interoperable with other components, regardless of what organization develops them. For platform service providers and MOD management, MCT must be cost effective, maintainable and evolvable. MCT software is built from components that are presented to users as composable user objects. A user object is an entity that represents a domain object such as a telemetry point, a command, a timeline, an activity, or a step in a procedure. User objects may be composed and reused, for example a telemetry point may be used in a traditional monitoring display, and that same telemetry user object may be composed into a procedure step. In either display, that same telemetry point may be shown in different views, such as a plot, an alpha numeric, or a meta-data view and those views may be changed live and in place. MCT presents users with a single unified user environment that contains all the objects required to perform applicable flight controller tasks, thus users do not have to use multiple applications, the traditional boundaries that exist between multiple heterogeneous applications disappear, leaving open the possibility of new operations concepts that are not constrained by the traditional applications paradigm.

Trimble, Jay Phillip↗

Airspace Systems Program: Next Generation Air Transportation System, NextGen Systems Analysis, Integration and Evaluation Project: Project Plan - Version 1.0

The key objectives of the NASA ASP are to: Improve mobility, capacity efficiency and access of the airspace system. Improve collaboration, predictability, and flexibility for the airspace users. Enable accurate modeling and simulation of air transportation systems. Accommodate operations of all classes of aircraft. Maintain system safety and environmental protection. In support of these program objectives, the major goal of the NextGen-SAIE Project is to enable the transition of key capacity and efficiency improvements to the NAS. Since many aspects of the NAS are unique to specific airport or airspace environments, demand on various parts of the NAS is not expected to increase equally as system demand grows. SAIE will provide systems level analysis of the NAS characteristics, constraints, and demands such that a suite of capacity-increasing concepts and technologies for system solutions are enabled and facilitated. The technical objectives in support of this goal are the following: Integration, evaluation, and transition of more mature concepts and technologies in an environment that faithfully emulates real-world complexities. Interoperability research and analysis of ASP technologies across ATM functions is performed to facilitate integration and take ASP concepts and technologies to higher Technology Readiness Level (TRL). Analyses are conducted on the program s concepts to identify the system benefits or impacts. System level analysis is conducted to increase understanding of the characteristics and constraints of airspace system and its domains.

Quon, Leighton↗

C-Band Airport Surface Communications System Standards Development. Phase II Final Report. Volume 1: Concepts of Use, Initial System Requirements, Architecture, and AeroMACS Design Considerations

This report is provided as part of ITT s NASA Glenn Research Center Aerospace Communication Systems Technical Support (ACSTS) contract NNC05CA85C, Task 7: New ATM Requirements-Future Communications, C-Band and L-Band Communications Standard Development and was based on direction provided by FAA project-level agreements for New ATM Requirements-Future Communications. Task 7 included two subtasks. Subtask 7-1 addressed C-band (5091- to 5150-MHz) airport surface data communications standards development, systems engineering, test bed and prototype development, and tests and demonstrations to establish operational capability for the Aeronautical Mobile Airport Communications System (AeroMACS). Subtask 7-2 focused on systems engineering and development support of the L-band digital aeronautical communications system (L-DACS). Subtask 7-1 consisted of two phases. Phase I included development of AeroMACS concepts of use, requirements, architecture, and initial high-level safety risk assessment. Phase II builds on Phase I results and is presented in two volumes. Volume I (this document) is devoted to concepts of use, system requirements, and architecture, including AeroMACS design considerations. Volume II describes an AeroMACS prototype evaluation and presents final AeroMACS recommendations. This report also describes airport categorization and channelization methodologies. The purposes of the airport categorization task were (1) to facilitate initial AeroMACS architecture designs and enable budgetary projections by creating a set of airport categories based on common airport characteristics and design objectives, and (2) to offer high-level guidance to potential AeroMACS technology and policy development sponsors and service providers. A channelization plan methodology was developed because a common global methodology is needed to assure seamless interoperability among diverse AeroMACS services potentially supplied by multiple service providers.

Hall, Edward↗

C-Band Airport Surface Communications System Standards Development. Phase II Final Report. Volume 2: Test Bed Performance Evaluation and Final AeroMACS Recommendations

This report is provided as part of ITT s NASA Glenn Research Center Aerospace Communication Systems Technical Support (ACSTS) contract NNC05CA85C, Task 7: New ATM Requirements-Future Communications, C-Band and L-Band Communications Standard Development and was based on direction provided by FAA project-level agreements for New ATM Requirements-Future Communications. Task 7 included two subtasks. Subtask 7-1 addressed C-band (5091- to 5150-MHz) airport surface data communications standards development, systems engineering, test bed and prototype development, and tests and demonstrations to establish operational capability for the Aeronautical Mobile Airport Communications System (AeroMACS). Subtask 7-2 focused on systems engineering and development support of the L-band digital aeronautical communications system (L-DACS). Subtask 7-1 consisted of two phases. Phase I included development of AeroMACS concepts of use, requirements, architecture, and initial high-level safety risk assessment. Phase II builds on Phase I results and is presented in two volumes. Volume I is devoted to concepts of use, system requirements, and architecture, including AeroMACS design considerations. Volume II (this document) describes an AeroMACS prototype evaluation and presents final AeroMACS recommendations. This report also describes airport categorization and channelization methodologies. The purposes of the airport categorization task were (1) to facilitate initial AeroMACS architecture designs and enable budgetary projections by creating a set of airport categories based on common airport characteristics and design objectives, and (2) to offer high-level guidance to potential AeroMACS technology and policy development sponsors and service providers. A channelization plan methodology was developed because a common global methodology is needed to assure seamless interoperability among diverse AeroMACS services potentially supplied by multiple service providers.

Hall, Edward↗

DARPA DTN Phase 3 Core Engineering Support

This report covers the initial DARPA DTN Phase 3 activities as JPL provided Core Engineering Support to the DARPA DTN Program, and then further details the culmination of the Phase 3 Program with a systematic development, integration and test of a disruption-tolerant C2 Situation Awareness (SA) system that may be transitioned to the USMC and deployed in the near future. The system developed and tested was a SPAWAR/JPL-Developed Common Operating Picture Fusion Tool called the Software Interoperability Environment (SIE), running over Disruption Tolerant Networking (DTN) protocols provided by BBN and MITRE, which effectively extends the operational range of SIE from normal fully-connected internet environments to the mobile tactical edges of the battlefield network.

Disruption Tolerant Networking (DTN) protocols↗

A New User Interface for On-Demand Customizable Data Products for Sensors in a SensorWeb

A SensorWeb is a set of sensors, which can consist of ground, airborne and space-based sensors interoperating in an automated or autonomous collaborative manner. The NASA SensorWeb toolbox, developed at NASA/GSFC in collaboration with NASA/JPL, NASA/Ames and other partners, is a set of software and standards that (1) enables users to create virtual private networks of sensors over open networks; (2) provides the capability to orchestrate their actions; (3) provides the capability to customize the output data products and (4) enables automated delivery of the data products to the users desktop. A recent addition to the SensorWeb Toolbox is a new user interface, together with web services co-resident with the sensors, to enable rapid creation, loading and execution of new algorithms for processing sensor data. The web service along with the user interface follows the Open Geospatial Consortium (OGC) standard called Web Coverage Processing Service (WCPS). This presentation will detail the prototype that was built and how the WCPS was tested against a HyspIRI flight testbed and an elastic computation cloud on the ground with EO-1 data. HyspIRI is a future NASA decadal mission. The elastic computation cloud stores EO-1 data and runs software similar to Amazon online shopping.

Mandl, Daniel↗

Motion Imagery and Robotics Application (MIRA)

Objectives include: I. Prototype a camera service leveraging the CCSDS Integrated protocol stack (MIRA/SM&C/AMS/DTN): a) CCSDS MIRA Service (New). b) Spacecraft Monitor and Control (SM&C). c) Asynchronous Messaging Service (AMS). d) Delay/Disruption Tolerant Networking (DTN). II. Additional MIRA Objectives: a) Demo of Camera Control through ISS using CCSDS protocol stack (Berlin, May 2011). b) Verify that the CCSDS standards stack can provide end-to-end space camera services across ground and space environments. c) Test interoperability of various CCSDS protocol standards. d) Identify overlaps in the design and implementations of the CCSDS protocol standards. e) Identify software incompatibilities in the CCSDS stack interfaces. f) Provide redlines to the SM&C, AMS, and DTN working groups. d) Enable the CCSDS MIRA service for potential use in ISS Kibo camera commanding. e) Assist in long-term evolution of this entire group of CCSDS standards to TRL 6 or greater.

Martinez, Lindolfo↗

Kennedy Space Center ITC-1 Internship Overview

As an intern for Priscilla Elfrey in the ITC-1 department, I was involved in many activities that have helped me to develop many new skills. I supported four different projects during my internship, which included the Center for Life Cycle Design (CfLCD), SISO Space Interoperability Smackdown, RTI Teacher Mentor Program, and the Discrete Event Simulation Integrated Visualization Environment Team (DIVE). I provided the CfLCD with web based research on cyber security initiatives involving simulation, education for young children, cloud computing, Otronicon, and Science, Technology, Engineering, and Mathematics (STEM) education initiatives. I also attended STEM meetings regarding simulation courses, and educational course enhancements. To further improve the SISO Simulation event, I provided observation feedback to the technical advisory board. I also helped to set up a chat federation for HLA. The third project involved the RTI Teacher Mentor program, which I helped to organize. Last, but not least, I worked with the DIVE team to develop new software to help visualize discrete event simulations. All of these projects have provided experience on an interdisciplinary level ranging from speech and communication to solving complex problems using math and science.

Ni, Marcus↗

Standards and Specifications for Ground Processing of Space Vehicles: From an Aviation-Based Shuttle Project to Global Application

Proprietary or unique designs and operations are expected early in any industry's development, and often provide a competitive early market advantage. However, there comes a time when a product or industry requires standardization for the whole industry to advance...or survive. For the space industry, that time has come. Here, we will focus on standardization of ground processing for space vehicles and their ground systems. With the retirement of the Space Shuttle, and emergence of a new global space race, affordability and sustainability are more important now than ever. The growing commercialization of the space industry and current global economic environment are driving greater need for efficiencies to save time and money. More RLV's (Reusable Launch Vehicles) are being developed for the gains of reusability not achievable with traditional ELV's (Expendable Launch Vehicles). More crew/passenger vehicles are also being developed. All of this calls for more attention needed for ground processing-repeatedly before launch and after landing/recovery. RLV's should provide more efficiencies than ELV's, as long as MRO (Maintenance, Repair, and Overhaul) is well-planned-even for the unplanned problems. NASA's Space Shuttle is a primary example of an RLV which was supposed to thrive on reusability savings with efficient ground operations, but lessons learned show that costs were (and still are) much greater than expected. International standards and specifications can provide the commonality needed to simplify design and manufacturing as well as to improve safety, quality, maintenance, and operability. There are standards organizations engaged in the space industry, but ground processing is one of the areas least addressed. Challenges are encountered due to various factors often not considered during development. Multiple vehicle elements, sites, customers, and contractors pose various functional and integration difficulties. Resulting technical publication structures and methods are incongruent. Some processing products are still done on paper, some electronic, and many being converted in between. Business systems then are not fully compatible, and paper as well as electronic conversions are time-consuming and costly. NASA and its Shuttle contractors setup rules and systems to handle what has produced over 130 RLV launches, but they have had many challenges. Attempts have been made to apply aviation industry specifications to make the Shuttle more efficient with its ground processing. One efficiency project example was to make a Shuttle Maintenance Manual (SMM) based on the commercial ATA (Air Transport Association of America) Spec 100 for technical publications. This industry standard, along with others, has been a foundation for efficient global MRO of commercial airlines for years. A modified version was also made for some military aircraft. The SMM project found many similarities in Spec 100 which apply to the Shuttle, and room for expansion for space systems/structures not in aircraft. The SMM project team met with the ATA and representatives from NASA's X-33 and X-34 programs to discuss collaboration on a national space standard based on Spec 100. A pilot project was enabled for a subset of Shuttle systems. Full implementation was not yet achieved, X-33 and X-34 were cancelled, and the Shuttles were then designated for retirement. Nonetheless, we can learn from this project how to expand this concept to all space vehicle products. Since then, ATA has joined with ASD (AeroSpace and Defence Industries Association of Europe) and AIA (Aerospace Industries Association) to form a much-enhanced and expanded international specification: Sl000D, International Specification for Technical Publications. It includes air, land, and sea vehicles, missiles, support equipment, ordnance, and communications. It is used by a growing number of countries for commercial and government products. Its modular design is supported by a Common Source Dabase (CSDB), and COTS (commercial off-the-shelf) software is available for production of IETP's (Interactive Electronic Technical Publications). A few space industry products in Europe have begun to apply Sl000D already. Also, there are other related standards/specifications which have global implications. We have an opportunity to adapt Sl000D and possibly other standards for use with space vehicles and ground systems. Sl000D has plenty of flexibility to apply to any product needed. To successfully grow the viability of the space industry, all members, commercial and government, will need to engage cooperatively in developing and applying standards to move toward interoperability. If we leverage and combine the best existing space standards and specifications, develop new ones to address known gaps, and adapt the best applicable features from other industries, we can establish an infrastructure to not only accelerate current development, but also build longevity for a more cohesive international space community.

Ingalls, John↗

Astronomer's Proposal Tool

Astronomer's Proposal Tool (APT) is a computer program that assists astronomers in preparing their Phase 1 and Phase 2 Hubble Space Telescope science programs. APT is a successor to the Remote Proposal Submission System 2 (RPS2) program, which has been rendered obsolete by more recent advances in computer software and hardware. APT exploits advances associated with widespread use of the Internet, multiplatform visual development software tools, and overall increases in the power of desktop computer hardware, all in such a way as to make the preparation and submission of proposals more intuitive and make observatory operations less cumbersome. APT provides documentation and help that are friendly, up to date, and easily accessible to users of varying levels of expertise, while defining an extensible framework that is responsive to changes in both technology and observatory operations. APT consists of two major components: (1) a set of software tools that are intuitive, visual, and responsive and (2) an integrated software environment that unifies all the tools and makes them interoperable. The APT tools include the Visual Target Tuner, Proposal Editor, Exposure Planner, Bright Object Checker, and Visit Planner.

Krueger, Tony↗

Exploration Medical System Demonstration Project

A near-Earth Asteroid (NEA) mission will present significant new challenges including hazards to crew health created by exploring a beyond low earth orbit destination, traversing the terrain of asteroid surfaces, and the effects of variable gravity environments. Limited communications with ground-based personnel for diagnosis and consultation of medical events require increased crew autonomy when diagnosing conditions, creating treatment plans, and executing procedures. Scope: The Exploration Medical System Demonstration (EMSD) project will be a test bed on the International Space Station (ISS) to show an end-to-end medical system assisting the Crew Medical Officers (CMO) in optimizing medical care delivery and medical data management during a mission. NEA medical care challenges include resource and resupply constraints limiting the extent to which medical conditions can be treated, inability to evacuate to Earth during many mission phases, and rendering of medical care by a non-clinician. The system demonstrates the integration of medical technologies and medical informatics tools for managing evidence and decision making. Project Objectives: The objectives of the EMSD project are to: a) Reduce and possibly eliminate the time required for a crewmember and ground personnel to manage medical data from one application to another. b) Demonstrate crewmember's ability to access medical data/information via a software solution to assist/aid in the treatment of a medical condition. c) Develop a common data management architecture that can be ubiquitously used to automate repetitive data collection, management, and communications tasks for all crew health and life sciences activities. d) Develop a common data management architecture that allows for scalability, extensibility, and interoperability of data sources and data users. e) Lower total cost of ownership for development and sustainment of peripheral hardware and software that use EMSD for data management f) Provide better crew health via the reduction in crew errors, crew time, and ground time.

Chin, D. A.↗

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↗

Dynamic Weather Routes: A Weather Avoidance Concept for Trajectory-Based Operations

The integration of convective weather modeling with trajectory automation for conflict detection, trial planning, direct routing, and auto resolution has uncovered a concept that could help controllers, dispatchers, and pilots identify improved weather routes that result in significant savings in flying time and fuel burn. Trajectory automation continuously and automatically monitors aircraft in flight to find those that could potentially benefit from improved weather reroutes. Controllers, dispatchers, and pilots then evaluate reroute options to assess their suitability given current weather and traffic. In today's operations aircraft fly convective weather avoidance routes that were implemented often hours before aircraft approach the weather and automation does not exist to automatically monitor traffic to find improved weather routes that open up due to changing weather conditions. The automation concept runs in real-time and employs two keysteps. First, a direct routing algorithm automatically identifies flights with large dog legs in their routes and therefore potentially large savings in flying time. These are common - and usually necessary - during convective weather operations and analysis of Fort Worth Center traffic shows many aircraft with short cuts that indicate savings on the order of 10 flying minutes. The second and most critical step is to apply trajectory automation with weather modeling to determine what savings could be achieved by modifying the direct route such that it avoids weather and traffic and is acceptable to controllers and flight crews. Initial analysis of Fort Worth Center traffic suggests a savings of roughly 50% of the direct route savings could be achievable.The core concept is to apply trajectory automation with convective weather modeling in real time to identify a reroute that is free of weather and traffic conflicts and indicates enough time and fuel savings to be considered. The concept is interoperable with today's integrated FMS/datalink. Auxiliary(lat/long) waypoints define a minimum delay reroute between current position and a downstream capture fix beyond the weather. These auxiliary waypoints can be uplinked to equipped aircraft and auto-loaded into the FMS. Alternatively, for unequipped aircraft, auxiliary waypoints can be replaced by nearby named fixes, but this could reduce potential savings. The presentation includes an overview of the automation approach and focuses on several cases in terms of potential savings, reroute complexity, best auxiliary waypoint solution vs. named fix solution, and other metrics.

McNally, B. David↗

PDS4: Developing the Next Generation Planetary Data System

The Planetary Data System (PDS) is in the midst of a major upgrade to its system. This upgrade is a critical modernization of the PDS as it prepares to support the future needs of both the mission and scientific community. It entails improvements to the software system and the data standards, capitalizing on newer, data system approaches. The upgrade is important not only for the purpose of capturing results from NASA planetary science missions, but also for improving standards and interoperability among international planetary science data archives. As the demands of the missions and science community increase, PDS is positioning itself to evolve and meet those demands.

Crichton, D.↗

Interplanetary Overlay Network Bundle Protocol Implementation

The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.

Burleigh, Scott C.↗

Software-Defined Radio for Space-to-Space Communications

A paper describes the Space- to-Space Communications System (SSCS) Software- Defined Radio (SDR) research project to determine the most appropriate method for creating flexible and reconfigurable radios to implement wireless communications channels for space vehicles so that fewer radios are required, and commonality in hardware and software architecture can be leveraged for future missions. The ability to reconfigure the SDR through software enables one radio platform to be reconfigured to interoperate with many different waveforms. This means a reduction in the number of physical radio platforms necessary to support a space mission s communication requirements, thus decreasing the total size, weight, and power needed for a mission.

Fisher, Ken↗

Effective Utilization of Resources and Infrastructure for a Spaceport Network Architecture

Providing routine, affordable access to a variety of orbital and deep space destinations requires an intricate network of ground, planetary surface, and space-based spaceports like those on Earth (land and sea), in various Earth orbits, and on other extraterrestrial surfaces. Advancements in technology and international collaboration are critical to establish a spaceport network that satisfies the requirements for private and government research, exploration, and commercial objectives. Technologies, interfaces, assembly techniques, and protocols must be adapted to enable mission critical capabilities and interoperability throughout the spaceport network. The conceptual space mission architecture must address the full range of required spaceport services, from managing propellants for a variety of spacecraft to governance structure. In order to accomplish affordability and sustainability goals, the network architecture must consider deriving propellants from in situ planetary resources to the maximum extent possible. Water on the Moon and Mars, Mars' atmospheric CO2, and O2 extracted from lunar regolith are examples of in situ resources that could be used to generate propellants for various spacecraft, orbital stages and trajectories, and the commodities to support habitation and human operations at these destinations. The ability to use in-space fuel depots containing in situ derived propellants would drastically reduce the mass required to launch long-duration or deep space missions from Earth's gravity well. Advances in transformative technologies and common capabilities, interfaces, umbilicals, commodities, protocols, and agreements will facilitate a cost-effective, safe, reliable infrastructure for a versatile network of Earth- and extraterrestrial spaceports. Defining a common infrastructure on Earth, planetary surfaces, and in space, as well as deriving propellants from in situ planetary resources to construct in-space propellant depots to serve the spaceport network, will reduce exploration costs due to standardization of infrastructure commonality and reduction in number and types of interfaces and commodities.

Gill, Tracy↗