Search NASASearch

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

Tool interoperability in SSE OI 2.0

This paper presents a review of the concept and implementation of tool interoperability in the Space Station Software Support Environment (SSE) OI 2.0. By first providing a description of SSE, the paper describes the problem at hand, that is; the nature of the SSE that gives rise to the requirement for interoperability--between SSE workstations and hence, between the tools which reside on the workstations. Specifically, word processor and graphic tool interoperability are discussed. The concept for interoperability that is implemented in OI 2.0 is described, as is an overview of the implementation strategy. Some of the significant challenges that the development team had to overcome to bring about interoperability are described, perhaps as a checklist, or warning, to others who would bring about tool interoperability. Lastly, plans to extend tool interoperability to a third class of tools in OI 3.0 are described.

Carmody, C. L.

A Deeper Dive Into the Meaning and Implications of Interoperability for LunaNet Communications and Navigation Services

As part of planning efforts for cislunar exploration and science missions, space agencies have been collaborating with each other to enable communications, networking, Position, Navigation, and Timing (PNT) systems to exchange information and provide services to spacecraft and space systems in transit, in orbit, and on the surface, thus helping each other to achieve their common goals. To achieve commonality and lower cost for mutual benefit, the strategy of interoperability is being adopted to help all the pieces fit together and function smoothly. Interoperability gives cislunar users the ability to operate in a collaborative environment similar to the terrestrial Internet, allowing them to share information, navigate safely despite increasing radio frequency congestion, and follow common processes and procedures for effective joint operations. Unlike prior government-dominated efforts, this ecosystem is expected to include commercial for-profit businesses, non-profit organizations, and academic institutions. Ultimately, the goal is to enable a cislunar ecosystem of service providers and users to contribute and/or utilize infrastructure and capabilities to accomplish mission objectives spanning the full range of human endeavours while supporting a variety of business models. This paper reports on the results of an effort to assist in efforts to frame the development of the international LunaNet architecture by providing a canonical definition of interoperability broad enough to meet these needs, examine architectural and operational implications of the definition, and explore interoperability strategies and tactics for deploying and evolving these services. It describes key systems-of-systems (SoS) (Network-of-Networks) interoperability concepts in the context of sustainment of the ecosystem over time as systems evolve in technologies, standards and Standards Development Organizations, component and subsystem upgrades, and user applications

LunaNet

Deeper Dive into Interoperability and Its Implications for LunaNet Communications and Navigation Services

The Artemis program being developed by United States’ (US) National Aeronautics and Space Administration (NASA) is developing the capabilities to return humans to the Moon and establish an initial base camp and associated infrastructure with extensive contributions from international and commercial partners. In planning for cislunar exploration and science missions, space agencies are collaborating to enable communications, networking, and Positioning, Navigation, and Timing (PNT) systems—called LunaNet—to exchange information and provide services to cislunar spacecraft and space systems, thus helping each other to achieve their shared goals. To achieve commonality and lower cost for mutual benefit, the strategy of interoperability is being adopted to help fit all the pieces together and function smoothly. Facilitating interoperability should benefit lunar missions by providing the ability to operate in a collaborative environment similar to the terrestrial Internet. Interoperability allows them to share information, navigate safely despite increasing radio frequency congestion, and follow common processes and procedures for effective joint operations. Unlike prior government-dominated efforts, this ecosystem is expected to include and benefit for-profit (commercial) businesses, non-profit organizations, and academic institutions as active stakeholders. Ultimately, the goal is to enable a cislunar ecosystem of service providers and users to contribute to and/or utilize infrastructure and capabilities to achieve mission objectives that span the full range of human endeavors while supporting a variety of business models. This approach enables a Systems of Systems (SoS), such as a Network-of-Networks, to be sustainable in the context of the LunaNet ecosystem as systems evolve over time in technologies, standards, components, and user applications. This paper reports on the results of an effort to help frame the development of the international LunaNet architecture by providing a canonical definition of interoperability broad enough to meet these needs, examining architectural and operational implications of the definition, and exploring interoperability strategies and tactics to deploy and evolve the services proposed for cislunar exploration and science missions.

interoperability

Space Network Interoperability Panel (SNIP) study

The Space Network Interoperability Panel (SNIP) study is a tripartite study that involves the National Aeronautics and Space Administration (NASA), the European Space Agency (ESA), and the National Space Development Agency (NASDA) of Japan. SNIP involves an ongoing interoperability study of the Data Relay Satellite (DRS) Systems of the three organizations. The study is broken down into two parts; Phase one deals with S-band (2 GHz) interoperability and Phase two deals with Ka-band (20/30 GHz) interoperability (in addition to S-band). In 1987 the SNIP formed a Working Group to define and study operations concepts and technical subjects to assure compatibility of the international data relay systems. Since that time a number of Panel and Working Group meetings have been held to continue the study. Interoperability is of interest to the three agencies because it offers a number of potential operation and economic benefits. This paper presents the history and status of the SNIP study.

Ryan, Thomas

Space Network Interoperability Panel (SNIP) study

The Space Network Interoperability Panel (SNIP) is described in terms of the panel's composition, purpose, history, and ongoing activities. SNIP is a consortium comprising NASA, ESA, and NASDA that is dedicated to the study of interoperability of the data-relay satellite (DRS) systems of the three groups. S-band and Ka-band interoperability are addressed by the SNIP study program by means of defining operations concepts, technical subjects, and other matters relevant to international DRS system compatibility. The potential users of the interoperability scheme are listed, cross-support techniques are described, and the load situations of the three agencies are characterized. A common 'interoperability frequency framework' is proposed, and both left-and right-hand circular polarization are incorporated to enhance flexibility and minimize interference. An operations concept is outlined based on these and other recommendations as developed by the international SNIP study.

Ryan, Thomas

NASA's Geospatial Interoperability Office(GIO)Program

NASA produces vast amounts of information about the Earth from satellites, supercomputer models, and other sources. These data are most useful when made easily accessible to NASA researchers and scientists, to NASA's partner Federal Agencies, and to society as a whole. A NASA goal is to apply its data for knowledge gain, decision support and understanding of Earth, and other planetary systems. The NASA Earth Science Enterprise (ESE) Geospatial Interoperability Office (GIO) Program leads the development, promotion and implementation of information technology standards that accelerate and expand the delivery of NASA's Earth system science research through integrated systems solutions. Our overarching goal is to make it easy for decision-makers, scientists and citizens to use NASA's science information. NASA's Federal partners currently participate with NASA and one another in the development and implementation of geospatial standards to ensure the most efficient and effective access to one another's data. Through the GIO, NASA participates with its Federal partners in implementing interoperability standards in support of E-Gov and the associated President's Management Agenda initiatives by collaborating on standards development. Through partnerships with government, private industry, education and communities the GIO works towards enhancing the ESE Applications Division in the area of National Applications and decision support systems. The GIO provides geospatial standards leadership within NASA, represents NASA on the Federal Geographic Data Committee (FGDC) Coordination Working Group and chairs the FGDC's Geospatial Applications and Interoperability Working Group (GAI) and supports development and implementation efforts such as Earth Science Gateway (ESG), Space Time Tool Kit and Web Map Services (WMS) Global Mosaic. The GIO supports NASA in the collection and dissemination of geospatial interoperability standards needs and progress throughout the agency including areas such as ESE Applications, the SEEDS Working Groups, the Facilities Engineering Division (Code JX) and NASA's Chief Information Offices (CIO). With these agency level requirements GIO leads, brokers and facilitates efforts to, develop, implement, influence and fully participate in standards development internationally, federally and locally. The GIO also represents NASA in the OpenGIS Consortium and ISO TC211. The OGC has made considerable progress in regards to relations with other open standards bodies; namely ISO, W3C and OASIS. ISO TC211 is the Geographic and Geomatics Information technical committee that works towards standardization in the field of digital geographic information. The GIO focuses on seamless access to data, applications of data, and enabling technologies furthering the interoperability of distributed data. Through teaming within the Applications Directorate and partnerships with government, private industry, education and communities, GIO works towards the data application goals of NASA, the ESE Applications Directorate, and our Federal partners by managing projects in four categories: Geospatial Standards and Leadership, Geospatial One Stop, Standards Development and Implementation, and National and NASA Activities.

Weir, Patricia

Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and Their Technologies to Further Enable Interoperability

To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative a requirement to standardize and control the naming conventions of very disparate systems and technologies are emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation Initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation Initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and birds of a feather activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another

Bradford, Robert N.

Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and their Technologies to Further Enable Interoperability

To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative, a requirement to standardize and control the naming conventions of very disparate systems and technologies is emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and Birds of a Feather (BoF) activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another standards body or technologies that are currently not standardized. For activities one through three, we will provide the analysis by either discipline or technology with rationale, identification and brief description of requirements and precedence. For activity four, we will provide a list of current standards bodies e.g. IETF and a list of potential candidates.

Bradford, Robert N.

Interoperability Trends in Extravehicular Activity (EVA) Space Operations for the 21st Century

No other space operations in the 21 st century more comprehensively embody the challenges and dependencies of interoperability than EVA. This discipline is already functioning at an W1paralleled level of interagency, inter-organizational and international cooperation. This trend will only increase as space programs endeavor to expand in the face of shrinking budgets. Among the topics examined in this paper are hardware-oriented issues. Differences in design standards among various space participants dictate differences in the EVA tools that must be manufactured, flown and maintained on-orbit. Presently only two types of functional space suits exist in the world. However, three versions of functional airlocks are in operation. Of the three airlocks, only the International Space Station (ISS) Joint Airlock can accommodate both types of suits. Due to functional differences in the suits, completely different operating protocols are required for each. Should additional space suit or airlock designs become available, the complexity will increase. The lessons learned as a result of designing and operating within such a system are explored. This paper also examines the non-hardware challenges presented by interoperability for a discipline that is as uniquely dependent upon the individual as EVA. Operation of space suits (essentially single-person spacecrafts) by persons whose native language is not that of the suits' designers is explored. The intricacies of shared mission planning, shared control and shared execution of joint EVA's are explained. For example, once ISS is fully functional, the potential exists for two crewmembers of different nationality to be wearing suits manufactured and controlled by a third nation, while operating within an airlock manufactured and controlled by a fourth nation, in an effort to perform tasks upon hardware belonging to a fifth nation. Everything from training issues, to procedures development and writing, to real-time operations is addressed. Finally, this paper looks to the management challenges presented by interoperability in general. With budgets being reduced among all space-faring nations, the need to expand cooperation in the highly expensive field of human space operations is only going to intensify. The question facing management is not if the trend toward interoperation will continue, but how to best facilitate its doing so. Real-world EVA interoperability experience throughout the ShuttlelMir and ISS Programs is discussed to illustrate the challenges and

Miller, Gerald E.

An Interoperability Concept for Detect and Avoid and Collision Avoidance Systems: Results from a Human-In-The-Loop Simulation

The integration of Unmanned Aircraft Systems (UAS) into the National Airspace System (NAS) poses a variety of technical challenges to UAS developers and aviation regulators. In response to growing demand for access to civil airspace in the United States, the Federal Aviation Administration (FAA) has produced a roadmap identifying key areas requiring further research and development. One such technical challenge is the development of a "detect and avoid" system (DAA) capable of providing a means of compliance with the "see and avoid" requirement in manned aviation. The purpose of the DAA system is to support the pilot, situated at a ground control station (GCS), in maintaining "DAA well clear" of nearby aircraft through the use of GCS displays and alerts. In addition to its primary function of aiding the pilot in maintaining DAA well clear, the DAA system must also safely interoperate with existing NAS systems and operations, such as the airspace management procedures of air traffic controllers (ATC) and Collision Avoidance (CA) systems currently in use by manned aircraft, namely the Traffic Alert and Collision Avoidance System (TCAS II). It is anticipated that many UAS architectures will integrate both a DAA system and a TCAS II. It is therefore necessary to explicitly study the integration of DAA and TCAS II alerting structures and maneuver guidance formats to ensure that pilots understand the appropriate type and urgency of their response to the various alerts. This paper presents a concept of interoperability for the two systems. The concept was developed with the goal of avoiding any negative impact on the performance level of TCAS II while retaining a DAA system that still effectively enables pilots to maintain DAA well clear. The interoperability concept described in the paper focuses primarily on facilitating the transition from a late-stage DAA encounter (where a loss of DAA well clear is imminent) to a TCAS II Corrective Resolution Advisory (RA), which requires pilot compliance within five seconds of its issuance. The interoperability concept was presented to 10 participants (6 active UAS pilots and 4 active commercial pilots) in a medium-fidelity, human-in-the-loop simulation designed to stress different aspects of the DAA and TCAS II systems. Pilots' ability to maintain separation, their rate of compliance and response times using the interoperability concept are reported. Results indicated that pilots exhibited comprehension of, and appropriate prioritization within, the DAA-TCAS II combined alert structure. Pilots demonstrated a high rate of compliance with TCAS II RAs and were also seen to respond to corrective RAs within the five second requirement established for manned aircraft. The DAA system presented under test was also shown to be effective in supporting pilots' ability to maintain DAA well clear in the overwhelming majority of cases in which pilots had sufficient time to respond.

Rorie, R. Conrad

SpaceVPX Interoperability Assessment

The existing VMEbus (VersaModular Eurocard bus) International Trade Association (VITA)-78 industry standard, also known as SpaceVPX, is an avionics board- and chassis-level standard derived from the OpenVPX standard as defined in VITA-65. While VITA-65 defines backplane and board-level profiles from COTS vendors to ensure interoperability of products used in developing systems and subsystems, the VITA-78 standard defines SpaceVPX to incorporate fault tolerance features that are required by many spaceflight systems. However, VITA-78 allows so much flexibility that interoperability between modules cannot be assured. This assessment provides guidelines on the use of, and extensions to, the VITA-78 standard to enable avionics interoperability for future NASA missions. The assessment team was comprised of subject matter experts (SMEs) from Goddard Space Flight Center (GSFC), the Jet Propulsion Laboratory (JPL), Johnson Space Center (JSC), and Langley Research Center (LaRC). The team included valuable external consulting support from a SME who was a key participant in the development of the VITA-78 standard. The team had extensive collaboration with the NASA Space Technology Mission Directorate (STMD) High Performance Spaceflight Computing (HPSC) project, specifically in the development of SpaceVPX interconnect findings, observations, and NESC recommendations. To provide an understanding of the breadth of implementations that SpaceVPX must accommodate, multiple NASA use cases were analyzed to assess the requirements for SpaceVPX implementations across a wide range of NASA missions (Appendix C). Applications included crewed missions, science missions, and orbital and surface robotic systems. Product surveys were conducted to assess the level of industry support for SpaceVPX, applications, and the variations in their implementations (Appendix D). In-depth analysis was conducted in the areas of: (a) power management and distribution, (b) form factors and daughtercards, (c) interconnect, and (d) fault tolerance. Leveraging the use cases, product surveys, and SMEs from multiple NASA Centers, these areas were analyzed to determine the range of implementations permitted by the VITA-78 standard and potential interoperability issues. Applicable findings and NESC recommendations were provided for each area. During this assessment, there were multiple opportunities to engage with other agencies to learn about their interest in SpaceVPX, their strategies for implementing SpaceVPX-based systems, and their internal development efforts. These engagements also generated findings and NESC recommendations. Based on this assessment analysis, NESC recommendations were made regarding the feature set and module profiles to support NASA SpaceVPX implementations. This feature set includes restrictions on features in VITA-78, and extensions to the standard. Key recommendations in this area include the use of 10 Gigabit Ethernet and Peripheral Component Interconnect Express (PCIe) as high bandwidth interconnect on the backplane, the retention of SpaceWire interconnect for control functions, and support for 3U (unit) and 6U, form factors for NASA systems. Restrictions were proposed on the usage of user-defined signals to promote interoperability, and specific power managements and distribution schemes for 3U systems. Beyond the technical implementation of SpaceVPX, recommendations were made on areas that warrant further investigation. Primary among these is the recommendation for NASA to collaborate with other space-going agencies and industry to incorporate recommendations into a future ‘dot spec’ of VITA-78. This would ensure wide adoption and availability of the modules that comply with the specification. The assessment includes appendices with candidate module profiles that can be considered as a starting point for this activity, and example systems based on the recommendations. Follow-on studies are recommended for architectures beyond SpaceVPX to address potential enhancements including condensed set of interconnect, software required to implement protocol layers on the interconnect (and other features), alternative power architectures, and system-level testability.

SpaceVPX

Interoperability of Tools at the CCMC

The CCMC has a diverse set of tools in many languages that support utilization of simulation outputs accessible through CCMC interactive archives. Some model output post-processing and analysis tools are delivered to tCCMC by the community. One such model output post-processing/utilization tool developed by the CCMC is the open source Kamodo package. Kamodo is developed primarily in Python (with some C) and has already established strong interoperability with other Python libraries inside PyHC and out. While that interoperability is important, interoperability with other languages and tools is as important. Many models are written in Fortran or C, and their ability to pull in data from a Python tool or export directly to other analysis software in a different language will greatly increase scientific productivity. Interoperability within Python is important, but broader interoperability is just as important.

CCMC

UAS Integration in the NAS Project: DAA-TCAS Interoperability "mini" HITL Primary Results

At the May 2015 SC-228 meeting, requirements for TCAS II interoperability became elevated in priority. A TCAS interoperability workgroup was formed to identify and address key issues/questions. The TCAS workgroup came up with an initial list of questions and a plan to address those questions. As part of that plan, NASA proposed to run a mini HITL to address display, alerting and guidance issues. A TCAS Interoperability Workshop was held to determine potential display/alerting/guidance issues that could be explored in future NASA mini HITLS. Consensus on main functionality of DAA guidance when TCAS II RA occurs. Prioritized list of independent variables for experimental design. Set of use cases to stress TCAS Interoperability.

human systems integration

Observations and Recommendations for the Calibration of Landsat 8 OLI and Sentinel 2 MSI for Improved Data Interoperability

Combining data from multiple sensors into a single seamless time series, also known as data interoperability, has the potential for unlocking new understanding of how the Earth functions as a system. However, our ability to produce these advanced data sets is hampered by the differences in design and function of the various optical remote-sensing satellite systems. A key factor is the impact that calibration of these instruments has on data interoperability. To address this issue, a workshop with a panel of experts was convened in conjunction with the Pecora 20 conference to focus on data interoperability between Landsat and the Sentinel 2 sensors. Four major areas of recommendation were the outcome of the workshop. The first was to improve communications between satellite agencies and the remote-sensing community. The second was to adopt a collections-based approach to processing the data. As expected, a third recommendation was to improve calibration methodologies in several specific areas. Lastly, and the most ambitious of the four, was to develop a comprehensive process for validating surface reflectance products produced from the data sets. Collectively, these recommendations have significant potential for improving satellite sensor calibration in a focused manner that can directly catalyze efforts to develop data that are closer to being seamlessly interoperable.

calibration; geometric; radiometric; Landsat; Sent

SpaceFOM: An Interoperability Standard for Space Systems Simulations

There is a long history of simulation supporting space systems development. This includes relatively simple parametric simulations to more complex trajectory simulations to large scale integrated vehicle simulation. One area of relatively recent development is in the area of distributed or interoperable simulation. Distributed simulation has been in wide use by the US military for years but is being used more widely in the aerospace community. To support large scale distributed simulation, the military community has developed a number of standards to support a priori interoperability between large collections of disparate simulation. For example, the IEEE 1516 High Level Architecture (HLA) and the Real-time Platform Reference Federation Object Model (RPR FOM). While HLA is suitable for space systems, there are a number of design decisions made in the development of the RPR FOM that prevent it from working well for space applications. In order to address these deficiencies, the Simulation Interoperability Standards Organization (SISO) developed a new HLS-compatible interoperability standard to support the needs of complex space systems. This standard is the Space Reference Federation Object Model (SpaceFOM). This paper presents on overview of the SpaceFOM including the fundamentals of the SpaceFOM, the key features of the SpaceFOM, and how the SpaceFOM supports large scale distributed simulation of complex space systems.

SISO

SpaceFOM: An Interoperability Standard for Space Systems Simulations

There is a long history of simulation supporting space systems development. This includes relatively simple parametric simulations to more complex trajectory simulations to large scale integrated vehicle simulation. One area of relatively recent development is in the area of distributed or interoperable simulation. Distributed simulation has been in wide use by the US military for years but is being used more broadly in the aerospace community. To support large scale distributed simulation, the military community has developed a number of standards to support a-priori interoperability between large collections of disparate simulations. For example, the IEEE 1516 High Level Architecture (HLA) and the Real-time Platform Reference Federation Object Model (RPR FOM). While HLA is suitable for space systems, there are a number of design decisions made in the development of the RPR FOM that prevent it from working well for space applications. In order to address these deficiencies, the Simulation Interoperability Standards Organization (SISO) developed a new HLA-based interoperability standard to support the needs of complex space systems. This standard is the Space Reference Federation Object Model (SpaceFOM). This paper presents an overview of the SpaceFOM including the fundamentals of the SpaceFOM, the key features of the SpaceFOM, and how the SpaceFOM supports large scale distributed simulation of complex space systems.

SpaceFOM

Tool and data interoperability in the SSE system

Information is given in viewgraph form on tool and data interoperability in the Software Support Environment (SSE). Information is given on industry problems, SSE system interoperability issues, SSE solutions to tool and data interoperability, and attainment of heterogeneous tool/data interoperability.

Shotton, Chuck

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.