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 703 records · Page 39

Constellation's Command, Control, Communications and Information (C3I) Architecture

Operations concepts are highly effective for: 1) Developing consensus; 2) Discovering stakeholder needs, goals, objectives; 3) Defining behavior of system components (especially emergent behaviors). An interoperability standard can provide an excellent lever to define the capabilities needed for system evolution. Two categories of architectures are needed in a program of this size are: 1) Generic - Needed for planning, design and construction standards; 2) Specific - Needed for detailed requirement allocations, interface specs. A wide variety of architectural views are needed to address stakeholder concerns, including: 1) Physical; 2) Information (structure, flow, evolution); 3) Processes (design, manufacturing, operations); 4) Performance; 5) Risk.

constellation↗

Workflow Agents vs. Expert Systems: Problem Solving Methods in Work Systems Design

During the 1980s, a community of artificial intelligence researchers became interested in formalizing problem solving methods as part of an effort called "second generation expert systems" (2nd GES). How do the motivations and results of this research relate to building tools for the workplace today? We provide an historical review of how the theory of expertise has developed, a progress report on a tool for designing and implementing model-based automation (Brahms), and a concrete example how we apply 2nd GES concepts today in an agent-based system for space flight operations (OCAMS). Brahms incorporates an ontology for modeling work practices, what people are doing in the course of a day, characterized as "activities." OCAMS was developed using a simulation-to-implementation methodology, in which a prototype tool was embedded in a simulation of future work practices. OCAMS uses model-based methods to interactively plan its actions and keep track of the work to be done. The problem solving methods of practice are interactive, employing reasoning for and through action in the real world. Analogously, it is as if a medical expert system were charged not just with interpreting culture results, but actually interacting with a patient. Our perspective shifts from building a "problem solving" (expert) system to building an actor in the world. The reusable components in work system designs include entire "problem solvers" (e.g., a planning subsystem), interoperability frameworks, and workflow agents that use and revise models dynamically in a network of people and tools. Consequently, the research focus shifts so "problem solving methods" include ways of knowing that models do not fit the world, and ways of interacting with other agents and people to gain or verify information and (ultimately) adapt rules and procedures to resolve problematic situations.

Clancey, William J.↗

Wireless Network Communications Overview for Space Mission Operations

The mission of the On-Board Wireless Working Group (WWG) is to serve as a general CCSDS focus group for intra-vehicle wireless technologies. The WWG investigates and makes recommendations pursuant to standardization of applicable wireless network protocols, ensuring the interoperability of independently developed wireless communication assets. This document presents technical background information concerning uses and applicability of wireless networking technologies for space missions. Agency-relevant driving scenarios, for which wireless network communications will provide a significant return-on-investment benefiting the participating international agencies, are used to focus the scope of the enclosed technical information.

Fink, Patrick W.↗

An Intelligent Archive Testbed Incorporating Data Mining

Many significant advances have occurred during the last two decades in remote sensing instrumentation, computation, storage, and communication technology. A series of Earth observing satellites have been launched by U.S. and international agencies and have been operating and collecting global data on a regular basis. These advances have created a data rich environment for scientific research and applications. NASA s Earth Observing System (EOS) Data and Information System (EOSDIS) has been operational since August 1994 with support for pre-EOS data. Currently, EOSDIS supports all the EOS missions including Terra (1999), Aqua (2002), ICESat (2002) and Aura (2004). EOSDIS has been effectively capturing, processing and archiving several terabytes of standard data products each day. It has also been distributing these data products at a rate of several terabytes per day to a diverse and globally distributed user community (Ramapriyan et al. 2009). There are other NASA-sponsored data system activities including measurement-based systems such as the Ocean Data Processing System and the Precipitation Processing system, and several projects under the Research, Education and Applications Solutions Network (REASoN), Making Earth Science Data Records for Use in Research Environments (MEaSUREs), and the Advancing Collaborative Connections for Earth-Sun System Science (ACCESS) programs. Together, these activities provide a rich set of resources constituting a value chain for users to obtain data at various levels ranging from raw radiances to interdisciplinary model outputs. The result has been a significant leap in our understanding of the Earth systems that all humans depend on for their enjoyment, livelihood, and survival. The trend in the community today is towards many distributed sets of providers of data and services. Despite this, visions for the future include users being able to locate, fuse and utilize data with location transparency and high degree of interoperability, and being able to convert data to information and usable knowledge in an efficient, convenient manner, aided significantly by automation (Ramapriyan et al. 2004; NASA 2005). We can look upon the distributed provider environment with capabilities to convert data to information and to knowledge as an Intelligent Archive in the Context of a Knowledge Building system (IA-KBS). Some of the key capabilities of an IA-KBS are: Virtual Product Generation, Significant Event Detection, Automated Data Quality Assessment, Large-Scale Data Mining, Dynamic Feedback Loop, and Data Discovery and Efficient Requesting (Ramapriyan et al. 2004).

Ramapriyan, H.↗

Workshop Report on Virtual Worlds and Immersive Environments

The workshop revolved around three framing ideas or scenarios about the evolution of virtual environments: 1. Remote exploration: The ability to create high fidelity environments rendered from external data or models such that exploration, design and analysis that is truly interoperable with the physical world can take place within them. 2. We all get to go: The ability to engage anyone in being a part of or contributing to an experience (such as a space mission), no matter their training or location. It is the creation of a new paradigm for education, outreach, and the conduct of science in society that is truly participatory. 3. Become the data: A vision of a future where boundaries between the physical and the virtual have ceased to be meaningful. What would this future look like? Is this plausible? Is it desirable? Why and why not?

Langhoff, Stephanie R.↗

Lessons Learned for Cx PRACA. Constellation Program Problem Reporting, Analysis and Corrective Action Process and System

This slide presentation reviews the Constellation Program Problem Reporting, Analysis and Corrective Action Process and System (Cx PRACA). The goal of the Cx PRACA is to incorporate Lessons learned from the Shuttle, ISS, and Orbiter programs by creating a single tool for managing the PRACA process, that clearly defines the scope of PRACA applicability and what must be reported, and defines the ownership and responsibility for managing the PRACA process including disposition approval authority. CxP PRACA is a process, supported by a single information gathering data module which will be integrated with a single CxP Information System, providing interoperability, import and export capability making the CxP PRACA a more effective and user friendly technical and management tool.

Kelle, Pido I.↗

Space Communications and Navigation (SCaN) Integrated Network Architecture Definition Document (ADD): Executive Summary - Volume 1

The SCaN Program has defined an integrated network architecture that fully meets the Administrator s mandate to the Program, and will result in a NASA infrastructure capable of providing the needed and enabling communications services to future space missions. The integrated network architecture will increase SCaN operational efficiency and interoperability through standardization, commonality and technology infusion. It will enable NASA missions requiring advanced communication and tracking capabilities such as: a. Optical communication b. Antenna arraying c. Lunar and Mars Relays d. Integrated network management (service management and network control) and integrated service execution e. Enhanced tracking for navigation f. Space internetworking with DTN and IP g. End-to-end security h. Enhanced security services Moreover, the SCaN Program has created an Integrated Network Roadmap that depicts an orchestrated and coherent evolution path toward the target architecture, encompassing all aspects that concern network assets (i.e., operations and maintenance, sustaining engineering, upgrade efforts, and major development). This roadmap identifies major NASA ADPs, and shows dependencies and drivers among the various planned undertakings and timelines. The roadmap is scalable to accommodate timely adjustments in response to Agency needs, goals, objectives and funding. Future challenges to implementing this architecture include balancing user mission needs, technology development, and the availability of funding within NASA s priorities. Strategies for addressing these challenges are to: define a flexible architecture, update the architecture periodically, use ADPs to evaluate options and determine when to make decisions, and to engage the stakeholders in these evaluations. In addition, the SCaN Program will evaluate and respond to mission need dates for technical and operational capabilities to be provided by the SCaN integrated network. In that regard, the architecture defined in this ADD is scalable to accommodate programmatic and technical changes.

Younes, Badri A.↗

Joint Composable Object Model and LVC Methodology

Within the Department of Defense, multiple architectures are created to serve and fulfill one or several specific service or mission related LVC training goals. Multiple Object Models exist across and within those architectures and it is there that those disparate object models are a major source of interoperability problems when developing and constructing the training scenarios. The two most commonly used architectures are; HLA and TENA, with DIS and CTIA following close behind in terms of the number of users. Although these multiple architectures can share and exchange data the underlying meta-models for runtime data exchange are quite different, requiring gateways/translators to bridge between the different object model representations; while the Department of Defense's use of gateways are generally effective in performing these functions, as the LVC environment increases so too does the cost and complexity of these gateways. Coupled with the wide range of different object models across the various user communities we increase the propensity for run time errors, increased programmer stop gap measures during coordinated exercises, or failure of the system as a whole due to unknown or unforeseen incompatibilities. The Joint Composable Object Model (JCOM) project was established under an M&S Steering Committee (MSSC)-sponsored effort with oversight and control placed under the Joint Forces Command J7 Advanced Concepts Program Directorate. The purpose of this paper is to address the initial and the current progress that has been made in the following areas; the Conceptual Model Development Format, the Common Object Model, the Architecture Neutral Data Exchange Model (ANDEM), and the association methodology to allow the re-use of multiple architecture object models and the development of the prototype persistent reusable library.

Rheinsmith, Richard↗

Use of Dynamic Models and Operational Architecture to Solve Complex Navy Challenges

The United States Navy established 8 Maritime Operations Centers (MOC) to enhance the command and control of forces at the operational level of warfare. Each MOC is a headquarters manned by qualified joint operational-level staffs, and enabled by globally interoperable C41 systems. To assess and refine MOC staffing, equipment, and schedules, a dynamic software model was developed. The model leverages pre-existing operational process architecture, joint military task lists that define activities and their precedence relations, as well as Navy documents that specify manning and roles per activity. The software model serves as a "computational wind-tunnel" in which to test a MOC on a mission, and to refine its structure, staffing, processes, and schedules. More generally, the model supports resource allocation decisions concerning Doctrine, Organization, Training, Material, Leadership, Personnel and Facilities (DOTMLPF) at MOCs around the world. A rapid prototype effort efficiently produced this software in less than five months, using an integrated process team consisting of MOC military and civilian staff, modeling experts, and software developers. The work reported here was conducted for Commander, United States Fleet Forces Command in Norfolk, Virginia, code N5-0LW (Operational Level of War) that facilitates the identification, consolidation, and prioritization of MOC capabilities requirements, and implementation and delivery of MOC solutions.

Grande, Darby↗

Criteria for Evaluating Alternative Network and Link Layer Protocols for the NASA Constellation Program Communication Architecture

Selecting a communications and network architecture for future manned space flight requires an evaluation of the varying goals and objectives of the program, development of communications and network architecture evaluation criteria, and assessment of critical architecture trades. This paper uses Cx Program proposed exploration activities as a guideline; lunar sortie, outpost, Mars, and flexible path options are described. A set of proposed communications network architecture criteria are proposed and described. They include: interoperability, security, reliability, and ease of automating topology changes. Finally a key set of architecture options are traded including (1) multiplexing data at a common network layer vs. at the data link layer, (2) implementing multiple network layers vs. a single network layer, and (3) the use of a particular network layer protocol, primarily IPv6 vs. Delay Tolerant Networking (DTN). In summary, the protocol options are evaluated against the proposed exploration activities and their relative performance with respect to the criteria are assessed. An architectural approach which includes (a) the capability of multiplexing at both the network layer and the data link layer and (b) a single network layer for operations at each program phase, as these solutions are best suited to respond to the widest array of program needs and meet each of the evaluation criteria.

Benbenek, Daniel↗

The CEOS WGISS Atmospheric Composition Portal

Goal: Demonstrate the feasibility of connecting distributed atmospheric composition data and analysis tools into a common and shared web framework. Initial effort focused on: a) Collaboratively creating a web application within WDC-RSAT for comparison of satellite derived atmospheric composition datasets accessed from distributed data sources. b) Implementation of data access and interoperability standards. c) Sollicit feedback from paternal users; Especially from ACC participants.

Lynnes, Chris↗

Software Health Management: A Short Review of Challenges and Existing Techniques

Modern spacecraft (as well as most other complex mechanisms like aircraft, automobiles, and chemical plants) rely more and more on software, to a point where software failures have caused severe accidents and loss of missions. Software failures during a manned mission can cause loss of life, so there are severe requirements to make the software as safe and reliable as possible. Typically, verification and validation (V&V) has the task of making sure that all software errors are found before the software is deployed and that it always conforms to the requirements. Experience, however, shows that this gold standard of error-free software cannot be reached in practice. Even if the software alone is free of glitches, its interoperation with the hardware (e.g., with sensors or actuators) can cause problems. Unexpected operational conditions or changes in the environment may ultimately cause a software system to fail. Is there a way to surmount this problem? In most modern aircraft and many automobiles, hardware such as central electrical, mechanical, and hydraulic components are monitored by IVHM (Integrated Vehicle Health Management) systems. These systems can recognize, isolate, and identify faults and failures, both those that already occurred as well as imminent ones. With the help of diagnostics and prognostics, appropriate mitigation strategies can be selected (replacement or repair, switch to redundant systems, etc.). In this short paper, we discuss some challenges and promising techniques for software health management (SWHM). In particular, we identify unique challenges for preventing software failure in systems which involve both software and hardware components. We then present our classifications of techniques related to SWHM. These classifications are performed based on dimensions of interest to both developers and users of the techniques, and hopefully provide a map for dealing with software faults and failures.

Pipatsrisawat, Knot↗

BioNet Digital Communications Framework

BioNet v2 is a peer-to-peer middleware that enables digital communication devices to talk to each other. It provides a software development framework, standardized application, network-transparent device integration services, a flexible messaging model, and network communications for distributed applications. BioNet is an implementation of the Constellation Program Command, Control, Communications and Information (C3I) Interoperability specification, given in CxP 70022-01. The system architecture provides the necessary infrastructure for the integration of heterogeneous wired and wireless sensing and control devices into a unified data system with a standardized application interface, providing plug-and-play operation for hardware and software systems. BioNet v2 features a naming schema for mobility and coarse-grained localization information, data normalization within a network-transparent device driver framework, enabling of network communications to non-IP devices, and fine-grained application control of data subscription band width usage. BioNet directly integrates Disruption Tolerant Networking (DTN) as a communications technology, enabling networked communications with assets that are only intermittently connected including orbiting relay satellites and planetary rover vehicles.

Gifford, Kevin↗

CCSDS - Advancing Spaceflight Technology for International Collaboration

The Consultative Committee for Space Data Systems (CCSDS) has been developing data and communications standards since 1982, with the objective of providing interoperability for enabling international collaboration for spaceflight missions. As data and communications technology has advanced, CCSDS has progressed to capitalize on existing products when available and suitable for spaceflight, and to develop innovative new approaches when available products fail. The current scope of the CCSDS architecture spans the end-to-end data architecture of a spaceflight mission, with ongoing efforts to develop and standardize cutting-edge technology. This manuscript describes the overall architecture, the position of CCSDS in the standards and international mission community, and some CCSDS processes. It then highlights in detail several of the most interesting and critical technical areas in work right now, and how they support collaborative missions. Special topics include: Delay/Disruption Tolerant Networking (DTN), Asynchronous Message Service (AMS), Multispectral/Hyperspectral Data Compression (MHDC), Coding and Synchronization, Onboard Wireless, Spacecraft Monitor and Control, Navigation, Security, and Time Synchronization/Correlation. Broad international participation in development of CCSDS standards is encouraged.

Kearney, Mike↗

Rationale, Scenarios, and Profiles for the Application of the Internet Protocol Suite (IPS) in Space Operations

This greenbook captures some of the current, planned and possible future uses of the Internet Protocol (IP) as part of Space Operations. It attempts to describe how the Internet Protocol is used in specific scenarios. Of primary focus is low-earth-orbit space operations, which is referred to here as the design reference mission (DRM). This is because most of the program experience drawn upon derives from this type of mission. Application profiles are provided. This includes parameter settings programs have proposed for sending IP datagrams over CCSDS links, the minimal subsets and features of the IP protocol suite and applications expected for interoperability between projects, and the configuration, operations and maintenance of these IP functions. Of special interest is capturing the lessons learned from the Constellation Program in this area, since that program included a fairly ambitious use of the Internet Protocol.

Benbenek, Daniel B.↗

Wireless Sensor Networks for Developmental and Flight Instrumentation

Wireless sensor networks (WSN) based on the IEEE 802.15.4 Personal Area Network and ZigBee Pro 2007 standards are finding increasing use in home automation and smart energy markets providing a framework for interoperable software. The Wireless Connections in Space Project, funded by the NASA Engineering and Safety Center, is developing technology, metrics and requirements for next-generation spacecraft avionics incorporating wireless data transport. The team from Stennis Space Center and Mobitrum Corporation, working under a NASA SBIR grant, has developed techniques for embedding plug-and-play software into ZigBee WSN prototypes implementing the IEEE 1451 Transducer Electronic Datasheet (TEDS) standard. The TEDS provides meta-information regarding sensors such as serial number, calibration curve and operational status. Incorporation of TEDS into wireless sensors leads directly to building application level software that can recognize sensors at run-time, dynamically instantiating sensors as they are added or removed. The Ames Research Center team has been experimenting with this technology building demonstration prototypes for on-board health monitoring. Innovations in technology, software and process can lead to dramatic improvements for managing sensor systems applied to Developmental and Flight Instrumentation (DFI) aboard aerospace vehicles. A brief overview of the plug-and-play ZigBee WSN technology is presented along with specific targets for application within the aerospace DFI market. The software architecture for the sensor nodes incorporating the TEDS information is described along with the functions of the Network Capable Gateway processor which bridges 802.15.4 PAN to the TCP/IP network. Client application software connects to the Gateway and is used to display TEDS information and real-time sensor data values updated every few seconds, incorporating error detection and logging to help measure performance and reliability in relevant target environments. Test results from our prototype WSN running the Mobitrum software system are summarized and the implications to the scalability and reliability for DFI applications are discussed. Our demonstration system, incorporating sensors for life support system and structural health monitoring is described along with test results obtained by running the demonstration prototype in relevant environments such as the Wireless Habitat Testbed at Johnson Space Center in Houston. An operations concept for improved sensor process flow from design to flight test is outlined specific to the areas of Environmental Control and Life Support System performance characterization and structural health monitoring of human-rated spacecraft. This operations concept will be used to highlight the areas where WSN technology, particularly plug-and-play software based on IEEE 1451, can improve the current process, resulting in significant reductions in the technical effort, overall cost and schedule for providing DFI capability for future spacecraft. RELEASED -

Alena, Richard↗

Employing Geodatabases for Planetary Mapping Conduct - Requirements, Concepts and Solutions

Planetary geologic mapping has become complex in terms of merging and co-registering a variety of different datasets for analysis and mapping. But it has also become more convenient when it comes to conducting actual (geoscientific) mapping with the help of desktop Geographic Information Systems (GIS). The complexity and variety of data, however, are major issues that need to be taken care of in order to provide mappers with a consistent and easy-to-use mapping basis. Furthermore, a high degree of functionality and interoperability of various commercial and open-source GIS and remote sensing applications allow mappers to organize map data, map components and attribute data in a more sophisticated and intuitional way when compared to workflows 15 years ago. Integration of mapping results of different groups becomes an awkward task as each mapper follows his/her own style, especially if mapping conduct is not coordinated and organized programmatically. Problems of data homogenization start with various interpretations and implementations of planetary map projections and reference systems which form the core component of any mapping and analysis work. If the data basis is inconsistent, mapping results in terms of objects georeference become hard to integrate. Apart from data organization and referencing issues, which are important on the mapping as well as the data-processing side of every project, the organization of planetary geologic map units and attributes, as well as their representation within a common GIS environment, are key components that need to be taken care of in a consistent and persistent way.

vanGasselt, Stephan↗

Bridging the Gap between NASA Hydrological Data and the Geospatial Community

There is a vast and ever increasing amount of data on the Earth interconnected energy and hydrological systems, available from NASA remote sensing and modeling systems, and yet, one challenge persists: increasing the usefulness of these data for, and thus their use by, the geospatial communities. The Hydrology Data and Information Services Center (HDISC), part of the Goddard Earth Sciences DISC, has continually worked to better understand the hydrological data needs of the geospatial end users, to thus better able to bridge the gap between NASA data and the geospatial communities. This paper will cover some of the hydrological data sets available from HDISC, and the various tools and services developed for data searching, data subletting ; format conversion. online visualization and analysis; interoperable access; etc.; to facilitate the integration of NASA hydrological data by end users. The NASA Goddard data analysis and visualization system, Giovanni, is described. Two case examples of user-customized data services are given, involving the EPA BASINS (Better Assessment Science Integrating point & Non-point Sources) project and the CUAHSI Hydrologic Information System, with the common requirement of on-the-fly retrieval of long duration time series for a geographical point

Rui, Hualan↗