Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 37 records · Page 2

Maturity Model for Advancing Smart Grid Interoperability

Abstract—Interoperability is about the properties of devices and systems to connect and work properly. Advancing interoperability eases integration and maintenance of the resulting interconnection. This leads to faster integration, lower labor and component costs, predictability of projects and the resulting performance, and evolutionary paths for upgrade. When specifications are shared and standardized, competition and novel solutions can bring new value streams to the community of stakeholders involved. Advancing interoperability involves reaching agreement for how things join at their interfaces. The quality of the agreements and the alignment of parties involved in the agreement present challenges that are best met with process improvement techniques. The GridWise® Architecture Council (GWAC) sponsored by the United States Department of Energy is supporting an effort to use concepts from capability maturity models used in the software industry to advance interoperability of smart grid technology. An interoperability maturity model has been drafted and experience is being gained through trials on various types of projects and community efforts. This paper describes the value and objectives of maturity models, the nature of the interoperability maturity model and how it compares with other maturity models, and experiences gained with its use.

IEEE↗

Issues in Bi-Directional Interoperability between BIM and BEM

The state-of-the-art interoperability between Building Information Modeling (BIM) and Building Energy Modeling (BEM) is mainly one-way. BEM software like EnergyPlus takes design input from BIM and simulates the energy consumption of the building. BIM, however, is unable to leverage energy simulation results from BEM smoothly. This lack of bi-directional interoperability between BIM and BEM prevents buildings from seeking more energy-efficient design options and limits BIM applications in optimal generative design. In this research, the authors have conducted the following activities related to two-way interoperability between BIM and BEM: (1) surveyed its current status through literature review, (2) investigated barriers to the bi-directional interoperability, and (3) suggested possible approaches to enable bi-directional interoperability and research outlook in the field. As a result, the authors have identified three main barriers to BIM BEM interoperability, namely, inefficient collaboration, limited scope in information transformation, and lack of BEM to BIM transformation. Future directions are suggested to address these barriers.

building design↗

Lemnos Interoperable Security Program

The manner in which the control systems are being designed and operated in the energy sector is undergoing some of the most significant changes in history due to the evolution of technology and the increasing number of interconnections to other system. With these changes however come two significant challenges that the energy sector must face; 1) Cyber security is more important than ever before, and 2) Cyber security is more complicated than ever before. A key requirement in helping utilities and vendors alike in meeting these challenges is interoperability. While interoperability has been present in much of the discussions relating to technology utilized within the energy sector and especially the Smart Grid, it has been absent in the context of cyber security. The Lemnos project addresses these challenges by focusing on the interoperability of devices utilized within utility control systems which support critical cyber security functions. In theory, interoperability is possible with many of the cyber security solutions available to utilities today. The reality is that the effort required to achieve cyber security interoperability is often a barrier for utilities. For example, consider IPSec, a widely-used Internet Protocol to define Virtual Private Networks, or tunnels , to communicate securely through untrusted public and private networks. The IPSec protocol suite has a significant number of configuration options and encryption parameters to choose from, which must be agreed upon and adopted by both parties establishing the tunnel. The exercise in getting software or devices from different vendors to interoperate is labor intensive and requires a significant amount of security expertise by the end user. Scale this effort to a significant number of devices operating over a large geographical area and the challenge becomes so overwhelming that it often leads utilities to pursue solutions from a single vendor. These single vendor solutions may inadvertently lock utilities into proprietary and closed systems.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Interoperability Strategic Vision

The Interoperability Strategic Vision whitepaper aims to promote a common understanding of the meaning and characteristics of interoperability and to provide a strategy to advance the state of interoperability as applied to integration challenges facing grid modernization. This includes addressing the quality of integrating devices and systems and the discipline to improve the process of successfully integrating these components as business models and information technology improve over time. The strategic vision for interoperability described in this document applies throughout the electric energy generation, delivery, and end-use supply chain. Its scope includes interactive technologies and business processes from bulk energy levels to lower voltage level equipment and the millions of appliances that are becoming equipped with processing power and communication interfaces. A transformational aspect of a vision for interoperability in the future electric system is the coordinated operation of intelligent devices and systems at the edges of grid infrastructure. This challenge offers an example for addressing interoperability concerns throughout the electric system.

24 POWER TRANSMISSION AND DISTRIBUTION↗

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↗

Analysis of Magnetic Field Emissions and Shield Requirements for Interoperating High-Power EV Wireless Charging System

In this study, the magnetic field emission (MFE) is investigated for matching (identical primary and secondary couplers) and interoperating (different couplers) 11 kW wireless charging systems (WCS). The interoperating charging pads generate higher MFE than the matching charging-pads; hence, using interoperable couplers requires a more effective shielding. In this work, different shield topologies are investigated to suppress the MFE for interoperable conditions. Four 11 kW WCSs with the unipolar (uni) and bipolar (bi) transmitter (Tx) and receiver (Rx) pads has been investigated: 1) uniTx with uniRx, 2) uniTx with biRx, 3) biTx with uniRx, and 4) biTx with bi-Rx. The studied systems are designed for 11 kW WPT3 level with Z2 airgap class (140-150 mm) resembling the standard SAE-J2954. The WCSs are simulated in finite element analysis (FEA) and validated experimentally using a 11 kW biTx-biRx system. The experimental results match with the simulation results with <5% error. The FEA results show that a biTx needs a magnetic shield, and a uniTx needs an aluminum shield to meet the MFE under all interoperability and alignment conditions.

Mohammad, Mostak↗

Smart Grid Interoperability Maturity Model

The integration of automation associated with electricity resources (including transmission and distribution automation and demand-side resources operated by end-users) is key to supporting greater efficiencies and incorporating variable renewable resources and electric vehicles into the power system. The integration problems faced by this community are analogous to those faced in the health industry, emergency services, and other complex communities with many stakeholders. To highlight this issue and encourage communication and the development of a smart grid interoperability community, the GridWise Architecture Council (GWAC) created an Interoperability Context-Setting Framework. This "conceptual model" has been helpful to explain the importance of organizational alignment in addition to technical and informational interface specifications for "smart grid" devices and systems. As a next step to building a community sensitive to interoperability, the GWAC is investigating an interoperability maturity model (IMM) based on work done by others to address similar circumstances. The objective is to create a tool or set of tools that encourages a culture of interoperability in this emerging community. The tools would measure status and progress, analyze gaps, and prioritize efforts to improve the situation.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Reference Interoperability Procurement Language

Achieving interoperability involves reaching agreement on common interfaces and promoting interoperability through performance specifications. Effective integration practices are a simple, effective, and direct way of addressing the challenge. By deciding on an integration approach with well-defined interfaces and selecting systems and devices that conform to that approach and choosing integrators that have experience implementing the chosen approach, many problems can be avoided. No integration effort is seamless but by specifying interoperability requirements during the procurement process typical problems from ad hoc approaches can be avoided or reduced. By continuing this approach to its conclusion at the end of the procurement process, these same interoperability requirements may lead themselves to specified performance criteria that can be used to measure interoperability during implementation. The contractual language may contain performance incentives and penalties tied to these requirements as appropriate.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

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↗