Search NASA⌕ Search

SEARCH · Search NASA

Results for “interoperable”

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

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↗

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↗

Reminiscing about 15 years of interoperability efforts

Over the past fifteen years, our perspective on tackling information interoperability problems for web-based scholarship has evolved significantly. In this opinion piece, we look back at three efforts that we have been involved in that aptly illustrate this evolution: OAI-PMH, OAI-ORE, and Memento. Understanding that no interoperability specification is neutral, we attempt to characterize the perspectives and technical toolkits that provided the basis for these endeavors. With that regard, we consider repository-centric and web-centric interoperability perspectives, and the use of a Linked Data or a REST/HATEAOS technology stack, respectively. In addition, we lament the lack of interoperability across nodes that play a role in web-based scholarship, but end on a constructive note with some ideas regarding a possible path forward.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

Interoperability of Materials Database Systems in Support of Nuclear Energy Development and Potential Applications for Fuel Cell Material Selection

Materials database interoperability has been of great interest in recent years for information exchange in support of research and development (R&D). In response to data and knowledge sharing needs of the GenIV International Forum (GIF) for global collaboration in nuclear energy R&D, the European Commission JRC Institute for Energy and Transport (JRC-IET) and the Oak Ridge National Laboratory (ORNL) have established a materials database interoperability project that develops techniques for automated materials data exchange between systems hosted at the two institutes MatDB Online at JRC IET and the Gen IV Materials Handbook at ORNL, respectively. The work to enable automated exchange of data between the two systems leverages the XML data import and export functionalities of both systems in combination with recently developed standards for engineering materials data. The preliminary results of data communication between the two systems have demonstrated the feasibility and efficiency of materials database interoperability, which constructs an interoperation framework that can be seamlessly integrated into the high-throughput First Principles material databases and thus advance the discovery of novel materials in fuel cell applications.

36 MATERIALS SCIENCE↗

EVs-at-RISC: A Secure and Resilient Interoperable SCM Control System Architecture for Electric Vehicle’s-at-Scale (Final Technical Report)

The EVs-at-RISC project was a five-year research, development, and demonstration initiative to create foundational tools for utility-scale fleet aggregation and Smart Charge Management (SCM) of Electric Vehicles (EV), Electric Vehicle Charging Infrastructure (EVCI), and related Distributed Energy Resources (DER). Rather than seeking to develop and demonstrate highly perfected SCM algorithms and control strategies, this project instead focused on creating foundational software solutions that enable unprecedented digital interoperability across the communications technologies and vendor platforms used to manage EV , EVCI, and DER, as well as existing energy management infrastructure operated by utilities, grid operators, and aggregators. This project then extends these novel interoperability capabilities to develop and deploy powerful middleware abstractions across grid edge networks and EVCI/DER fleet aggregations incorporating modern software tools and best practices, such as CI/CD, to bring the immense capabilities of infrastructure-as-code and policy-as-code to modern grid edge network environments. This addresses the foremost systemic issues preventing realization of any net operational benefits from scaled deployment of behind-the-meter EV, EVCI, and DER assets in electric power grids and markets today. The results of this approach and project unlock massive potential for new SCM capabilities to be easily prototyped, evaluated, and deployed at-scale within the existing grid edge network infrastructure and EVCI/DER technology ecosystem. The EVs-at-RISC project achieves this by extending Open Field Message Bus (OpenFMB), a conceptual model for digital interoperability and distributed intelligence in traditional front-of-meter utility SCADA networks, validating our hypothesis that OpenFMB could be similarly used to solve systemic digital interoperability issues in behind-the-meter environments and unlock real-world utility-scale SCM capabilities without requiring any new proprietary vendor solutions or significant infrastructure reconfiguration.

24 POWER TRANSMISSION AND DISTRIBUTION↗

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↗