Search NASA⌕ Search

SEARCH · Search NASA

Results for “Interoperable interfaces”

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 19 records

Interoperability among Space Station Freedom data systems - A field test of standards

A development status evaluation is presented for NASA efforts toward the achievement of interoperability among Space Station Freedom (SSF) data systems, despite the complexity created by the number and wide distribution of such systems, the intensive international participation, and the use of time-phased development cycles. Four areas have been identified as essential: communications interoperability, data interoperability, and crew and payload interface interoperability. Accelerated efforts are needed to define and refine detailed interface designs before developments by each of the SSF's international partners come to take fundamentally incompatible courses.

Whitelaw, Virginia A.↗

International Space Power System Interoperability Standards (ISPSIS)

This International Space Power System Interoperability Standards(ISPSIS) is the result of collaborations within the International Space Station (ISS) and Gateway memberships to establish interoperable interfaces, terminology, and techniques, to facilitate collaborative endeavors of space exploration in cislunar and deep space environments. These standards are available for international and commercial partnerships. Standards that are established and internationally recognized have been selected where possible to enable a variety of providers. Increasing hardware commonality among providers while decreasing unique configurations has the potential to reduce the traditional barriers in space exploration: overall mass and volume required to execute a mission. Standardizing interfaces reduces the scope of the development effort. The information within this document represents a set of parameters, which if accommodated in the system architecture support greater efficiencies, promote cost savings, and increase the probability of mission success. These standards are not intended to specify system details needed for implementation nor do they dictate design features behind the interface; specific requirements will be defined in unique documents.

David James Sadey↗

CAD Services: an Industry Standard Interface for Mechanical CAD Interoperability

Most organizations seek to design and develop new products in increasingly shorter time periods. At the same time, increased performance demands require a team-based multidisciplinary design process that may span several organizations. One approach to meet these demands is to use 'Geometry Centric' design. In this approach, design engineers team their efforts through one united representation of the design that is usually captured in a CAD system. Standards-based interfaces are critical to provide uniform, simple, distributed services that enable the 'Geometry Centric' design approach. This paper describes an industry-wide effort, under the Object Management Group's (OMG) Manufacturing Domain Task Force, to define interfaces that enable the interoperability of CAD, Computer Aided Manufacturing (CAM), and Computer Aided Engineering (CAE) tools. This critical link to enable 'Geometry Centric' design is called: Cad Services V1.0. This paper discusses the features of this standard and proposed application.

Claus, Russell↗

Architecting the Communication and Navigation Networks for NASA's Space Exploration Systems

NASA is planning a series of short and long duration human and robotic missions to explore the Moon and then Mars. A key objective of the missions is to grow, through a series of launches, a system of systems communication, navigation, and timing infrastructure at minimum cost while providing a network-centric infrastructure that maximizes the exploration capabilities and science return. There is a strong need to use architecting processes in the mission pre-formulation stage to describe the systems, interfaces, and interoperability needed to implement multiple space communication systems that are deployed over time, yet support interoperability with each deployment phase and with 20 years of legacy systems. In this paper we present a process for defining the architecture of the communications, navigation, and networks needed to support future space explorers with the best adaptable and evolable network-centric space exploration infrastructure. The process steps presented are: 1) Architecture decomposition, 2) Defining mission systems and their interfaces, 3) Developing the communication, navigation, networking architecture, and 4) Integrating systems, operational and technical views and viewpoints. We demonstrate the process through the architecture development of the communication network for upcoming NASA space exploration missions.

Bhassin, Kul B.↗

Space Communications and Navigation (SCaN) Network Simulation Tool Development and Its Use Cases

In this work, we focus on the development of a simulation tool to assist in analysis of current and future (proposed) network architectures for NASA. Specifically, the Space Communications and Navigation (SCaN) Network is being architected as an integrated set of new assets and a federation of upgraded legacy systems. The SCaN architecture for the initial missions for returning humans to the moon and beyond will include the Space Network (SN) and the Near-Earth Network (NEN). In addition to SCaN, the initial mission scenario involves a Crew Exploration Vehicle (CEV), the International Space Station (ISS) and NASA Integrated Services Network (NISN). We call the tool being developed the SCaN Network Integration and Engineering (SCaN NI&E) Simulator. The intended uses of such a simulator are: (1) to characterize performance of particular protocols and configurations in mission planning phases; (2) to optimize system configurations by testing a larger parameter space than may be feasible in either production networks or an emulated environment; (3) to test solutions in order to find issues/risks before committing more significant resources needed to produce real hardware or flight software systems. We describe two use cases of the tool: (1) standalone simulation of CEV to ISS baseline scenario to determine network performance, (2) participation in Distributed Simulation Integration Laboratory (DSIL) tests to perform function testing and verify interface and interoperability of geographically dispersed simulations/emulations.

Jennings, Esther↗

Surface Systems and Interface Standardization

A key contribution to surface systems sustainability on Lunar and planetary surfaces is commonality between hardware and software interfaces. Generic interfaces for data, power, and fluids will reduce risk, promote interoperability, and define standard interfaces across surface exploration projects and programs. Standardized interfaces would be advantageous for improving efficiency and reducing overall complexity, which are critical considerations for future space exploration. Furthermore, it will provide cost reductions to NASA’s Artemis program over its life cycle (in Operations & Maintenance (O&M) and Logistics). Unique proprietary interfaces if considered or allowed would not only increase complexity but also add cost to the programs. Of course, understanding what will work and not work effectively in these unique environments such as the lunar surface is important. These unique environments require much needed intelligent design, prototyping, comprehensive testing, and field experience, utilizing consensus on common interface solutions.

Lunar↗

Human-In-The-Loop Investigation of Interoperability Between Terminal Sequencing and Spacing, Automated Terminal Proximity Alert, and Wake-Separation Recategorization

A human-in-the-loop simulation study addressed terminal-area controller-workstation interface variations for interoperability between three new capabilities being introduced by the FAA. The capabilities are Terminal Sequencing and Spacing (TSAS), Automated Terminal Proximity Alert (ATPA), and wake-separation recategorization, or 'RECAT.' TSAS provides controllers with Controller-Managed Spacing (CMS) tools, including slot markers, speed advisories, and early/late indications, together with runway assignments and sequence numbers. ATPA provides automatic monitor, warning, and alert cones to inform controllers about spacing between aircraft on approach. ATPA cones are sized according to RECAT, an improved method of specifying wake-separation standards. The objective of the study was to identify potential issues and provide recommendations for integrating TSAS with ATPA and RECAT. Participants controlled arrival traffic under seven different display configurations, then tested an 'exploratory' configuration developed with participant input. All the display conditions were workable and acceptable, but controllers strongly preferred having the CMS tools available on Feeder positions, and both CMS tools and ATPA available on Final positions. Controllers found the integrated systems favorable and liked being able to tailor configurations to individual preferences.

ATD-1↗

A Standard Reference Model for Data Archives

An implementable Data Archive Architecture is being developed for trusted digital repositories based on the Reference Model for an Open Archival Information System (OAIS) – ISO 14721. A set of interoperable protocols and interface specifications are planned that will offer capabilities for accessing, merging, and re-using data, both within and across the operational boundaries of trustworthy digital repositories. The model will also provide support for the fundamental scientific need to verify the reproducibility of results. This standards development task is being performed by the Data Archive Interoperability (DAI) working group within the Consultative Committee for Space Data Systems (CCSDS). The architecture integrates concepts from the OAIS Reference Model, the ISO/IEC 11179 Metadata Registry (MDR) standard, the CCSDS Reference Architecture for Space Information Management (RASIM), the proposed draft recommended practice document, Information Preparation to Enable Long Term Use (IPELTU), and three decades of digital repository development for science research.

Ambacher, Bruce↗

Khoros software specification format and interoperability

Khoros defines formats for User Interface Specification (UIS) and Program Specification (PS) files. From such files, its code generator, Ghostwriter, creates source files and documentation. The great advantage of the system is that the code fragments that make up part of the PS file are purely generic. All Khoros-related code is created by the code generator; this includes all user interface code. As a matter of fact, both specification files are very generic in nature. Thus, one could imagine using it as the basis for other software systems. A case is made that writing a code generator that would create IRAF-compatible code from the Khoros UIS and PS files is fairly trivial. Another aspect of the Khoros system conventions concerns the way execution commands are generated by the user interface and the actual syntax of those commands. The protocols are such that interoperability at the level of executable modules is readily possible.

Rots, A. H.↗

Toward a North American Standard for Mobile Data Services

The rapid introduction of digital mobile communications systems is an important part of the emerging digital communications scene. These developments pose both a potential problem and a challenge. On one hand, these separate market driven developments can result in an uncontrolled mixture of analog and digital links which inhibit data modem services across the mobile/Public Switched network (PSTN). On the other hand, the near coincidence of schedules for development of some of these systems, i.e., Digital Cellular, Mobile Satellite, Land Mobile Radio, and ISDN, provides an opportunity to address interoperability problems by defining interfaces, control, and service standards that are compatible among these new services. In this paper we address the problem of providing data services interoperation between mobile terminals and data devices on the PSTN. The expected data services include G3 Fax, asynchronous data, and the government's STU-3 secure voice system, and future data services such as ISDN. We address a common architecture and a limited set of issues that are key to interoperable mobile data services. We believe that common mobile data standards will both improve the quality of data service and simplify the systems for manufacturers, data users, and service providers.

Dean, Richard A.↗

NextSTEP Appendix A Modular ECLSS Effort Lessons Learned

NASA’s Artemis program provides the first steps for earth-independent exploration starting with crewed habitats in cislunar space and progressing toward crewed landings on the lunar surface that will prepare systems and crews for the exploration of Mars. The Next Space Technology for Exploration Partnerships (NextSTEP) is a public-private partnership model that facilitates commercial development of deep space exploration capabilities in support of more extensive human spaceflight missions in and beyond cislunar space. NASA issued the original NextSTEP Broad Agency Announcement (BAA) to U.S. industry in late 2014 and issued the second BAA (NextSTEP-2) in April 2016. The first appendix under NextSTEP-2, Appendix A, focused on developing deep space habitation concepts, engineering design and development, and risk reduction efforts leading to a habitation capability in cislunar space. NASA solicited concepts to develop and refine the evolvable, modular architecture, functional allocation options, standards, and common interfaces required to enable interoperability of the aggregate system to provide long duration deep space transit habitation, specifically enhancements and testing of deep space Environmental Control and Life Support Systems (ECLSS). Collins Aerospace, formerly UTC Aerospace Systems (UTAS), was awarded a Phase 1 and subsequent Phase 2 contract to “develop concepts that group ECLS systems into logical modules maximizing the use of common components and the development of unique methods and design concepts that support in-flight maintenance and repair for future exploration systems.” This paper summarizes the work accomplished under this effort, the lessons that can be applied to development of forthcoming habitation elements, and the gaps remaining to achieve a more resilient, maintainable, repairable and adaptable system capable of installation on a wide variety of habitat platforms. A primary accomplishment of this effort is the development and maturation of a modular palletization concept to enable standard rack interfaces, post-launch outfitting, and decoupling of structural supports that withstand launch environments from those needed for lower on-orbit loads in order to reduce installed mass and repurposing of panels within the habitat. In the course of the effort, Collins assessed numerous architecture trades, including the use of condensing and noncondensing heat exchangers, the ability of modular units to accommodate various habitat volumes and thermal loading, and the most appropriate order of and timing of delivery of regenerative ECLSS hardware to orbital habitats. In addition to the modularity of hardware elements, Collins developed software approaches for distributed/modular command, control, and communication systems and innovative Bayesian fault detection and isolation techniques. Finally, the effort explored advanced maintainability and supportability concepts including the definition of maintenance units (MUs) in place of the traditional Orbital Replacement Units (ORUs), increasing parts commonality to reduce the number and type of spare parts, the use of augmented reality to guide crews during maintenance and repair procedures, and how crews would prepare for and recover from long durations of habitat dormancy. Now that the NextSTEP Modular ECLSS effort has come to a close, it’s important to identify the lessons learned and where they can be leveraged to improve NASA’s broader program of ECLSS technology development and demonstration and ultimately how they can increase the performance of future surface and orbital habitats.

NextSTEP↗

NextSTEP Appendix A Modular ECLSS Effort Lessons Learned

NASA’s Artemis program provides the first steps for earth-independent exploration starting with crewed habitats in cislunar space and progressing toward crewed landings on the lunar surface that will prepare systems and crews for the exploration of Mars. The Next Space Technology for Exploration Partnerships (NextSTEP) is a public-private partnership model that facilitates commercial development of deep space exploration capabilities in support of more extensive human spaceflight missions in and beyond cislunar space. NASA issued the original NextSTEP Broad Agency Announcement (BAA) to U.S. industry in late 2014 and issued the second BAA (NextSTEP-2) in April 2016. The first appendix under NextSTEP-2, Appendix A, focused on developing deep space habitation concepts, engineering design and development, and risk reduction efforts leading to a habitation capability in cislunar space. NASA solicited concepts to develop and refine the evolvable, modular architecture, functional allocation options, standards, and common interfaces required to enable interoperability of the aggregate system to provide long duration deep space transit habitation, specifically enhancements and testing of deep space Environmental Control and Life Support Systems (ECLSS). Collins Aerospace, formerly UTC Aerospace Systems (UTAS), was awarded a Phase 1 and subsequent Phase 2 contract to “develop concepts that group ECLS systems into logical modules maximizing the use of common components and the development of unique methods and design concepts that support in-flight maintenance and repair for future exploration systems.” This paper summarizes the work accomplished under this effort, the lessons that can be applied to development of forthcoming habitation elements, and the gaps remaining to achieve a more resilient, maintainable, repairable and adaptable system capable of installation on a wide variety of habitat platforms. A primary accomplishment of this effort is the development and maturation of a modular palletization concept to enable standard rack interfaces, post-launch outfitting, and decoupling of structural supports that withstand launch environments from those needed for lower on-orbit loads in order to reduce installed mass and repurposing of panels within the habitat. In the course of the effort, Collins assessed numerous architecture trades, including the use of condensing and noncondensing heat exchangers, the ability of modular units to accommodate various habitat volumes and thermal loading, and the most appropriate order of and timing of delivery of regenerative ECLSS hardware to orbital habitats. In addition to the modularity of hardware elements, Collins developed software approaches for distributed/modular command, control, and communication systems and innovative Bayesian fault detection and isolation techniques. Finally, the effort explored advanced maintainability and supportability concepts including the definition of maintenance units (MUs) in place of the traditional Orbital Replacement Units (ORUs), increasing parts commonality to reduce the number and type of spare parts, the use of augmented reality to guide crews during maintenance and repair procedures, and how crews would prepare for and recover from long durations of habitat dormancy. Now that the NextSTEP Modular ECLSS effort has come to a close, it’s important to identify the lessons learned and where they can be leveraged to improve NASA’s broader program of ECLSS technology development and demonstration and ultimately how they can increase the performance of future surface and orbital habitats.

NextSTEP↗

Architecting Communication Network of Networks for Space System of Systems

The National Aeronautics and Space Administration (NASA) and the Department of Defense (DoD) are planning Space System of Systems (SoS) to address the new challenges of space exploration, defense, communications, navigation, Earth observation, and science. In addition, these complex systems must provide interoperability, enhanced reliability, common interfaces, dynamic operations, and autonomy in system management. Both NASA and the DoD have chosen to meet the new demands with high data rate communication systems and space Internet technologies that bring Internet Protocols (IP), routers, servers, software, and interfaces to space networks to enable as much autonomous operation of those networks as possible. These technologies reduce the cost of operations and, with higher bandwidths, support the expected voice, video, and data needed to coordinate activities at each stage of an exploration mission. In this paper, we discuss, in a generic fashion, how the architectural approaches and processes are being developed and used for defining a hypothetical communication and navigation networks infrastructure to support lunar exploration. Examples are given of the products generated by the architecture development process.

Bhasin, Kul B.↗

Current state of the mass storage system reference model

IEEE SSSWG was chartered in May 1990 to abstract the hardware and software components of existing and emerging storage systems and to define the software interfaces between these components. The immediate goal is the decomposition of a storage system into interoperable functional modules which vendors can offer as separate commercial products. The ultimate goal is to develop interoperable standards which define the software interfaces, and in the distributed case, the associated protocols to each of the architectural modules in the model. The topics are presented in viewgraph form and include the following: IEEE SSSWG organization; IEEE SSSWG subcommittees & chairs; IEEE standards activity board; layered view of the reference model; layered access to storage services; IEEE SSSWG emphasis; and features for MSSRM version 5.

Coyne, Robert↗

Enabling Interoperable Space Robots With the Joint Technical Architecture for Robotic Systems (JTARS)

Robots that operate independently of one another will not be adequate to accomplish the future exploration tasks of long-distance autonomous navigation, habitat construction, resource discovery, and material handling. Such activities will require that systems widely share information, plan and divide complex tasks, share common resources, and physically cooperate to manipulate objects. Recognizing the need for interoperable robots to accomplish the new exploration initiative, NASA s Office of Exploration Systems Research & Technology recently funded the development of the Joint Technical Architecture for Robotic Systems (JTARS). JTARS charter is to identify the interface standards necessary to achieve interoperability among space robots. A JTARS working group (JTARS-WG) has been established comprising recognized leaders in the field of space robotics including representatives from seven NASA centers along with academia and private industry. The working group s early accomplishments include addressing key issues required for interoperability, defining which systems are within the project s scope, and framing the JTARS manuals around classes of robotic systems.

Bradley, Arthur↗