Search NASA⌕ Search

SEARCH · Search NASA

Results for “INTEROPERABILITY”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 433 records · Page 24

Recommendations for Data-in-Transit Requirements for Securing DER Communications

With the adoption of Distributed Energy Resource (DER) interoperability standards, common communication protocols are now being deployed between power system operators and DER devices. In 2018, a revision to the US interconnection and interoperability standard, Institute of Electrical and Electronics Engineers (IEEE) Std. 1547, required DER equipment to have an IEEE 2030.5, IEEE 1815, or SunSpec Modbus communication exchange interface. This change supports the future transition to secure connection and exchange of information between the DER equipment and implementing parties, such as grid operators. Adoption of standardized communication protocols and associated information models is a critical step toward interoperability between power system operators and DER, such as photovoltaic (PV) and energy storage systems. However, security requirements for these standardized communication protocols are not comprehensive, resulting in non-standard and vendor-specific implementation that may leave DER equipment susceptible to cyberattacks. This paper examines the data-in-flight security requirements for standardized DER communication protocols, per IEEE 1547-2018 revision, as it relates to device authentication, key management, and encryption. The state of the art for these security features is also explored, addressing their impact on communication and performance of low-cost single board computers, which are typical of DER devices. In conclusion, a recommendation is provided to adopt a common set of communication requirements, which are intended to achieve interoperability and implement data security over DER network pathways, while ensuring reliable, secure, and real-time information delivery.

42 ENGINEERING↗

Metadata Schemas and Ontologies for Building Energy Applications: A Critical Review and Use Case Analysis

With the increasing digitalization of processes throughout the lifecycle of buildings, data exchanged between stakeholders and between building systems has grown significantly. However, a lack of semantic interoperability between data in different systems is still prevalent, hindering the development of applications that can be reused across buildings and limiting the scalability of innovative solutions. Semantics refers to the description of the meaning of the data in a way that can be consistently understood by applications. Recently, several competing initiatives have been developing metadata schemas and ontologies to express this semantic information for different applications in the building domain. This paper systematically reviews these schemas and conducts an analysis of five of them to evaluate their applicability to three high-value use cases for building operations: energy audits, automated fault detection and diagnostics and optimal control. The survey finds 40 schemas published in the last 10 years but but their actual use in industry is difficult to estimate. Among the five selected ontologies, several gaps are highlighted in relation to the three use cases. Recommendations for the future include better harmonization of these initiatives, more centralized repositories and search engines for these schemas as well as better industry engagement to facilitate their adoption.

Smart Building, Sematic, Metadata, Ontology, Data ↗

A Human View Model for Socio-Technical Interactions

The Human View was developed as an additional architectural viewpoint to focus on the human part of a system. The Human View can be used to collect and organize data in order to understand how human operators interact and impact the other elements of a system. This framework can also be used to develop a model to describe how humans interact with each other in network enabled systems. These socio-technical interactions form the foundation of the emerging area of Human Interoperability. Human Interoperability strives to understand the relationships required between human operators that impact collaboration across networked environments, including the effect of belonging to different organizations. By applying organizational relationship concepts from network theory to the Human View elements, and aligning these relationships with a model developed to identify layers of coalition interoperability, the conditions for different levels for Human Interoperability for network enabled systems can be identified. These requirements can then be captured in the Human View products to improve the overall network enabled system.

Handley, Holly A.↗

UAS Integration into the NAS: Detect and Avoid Display Evaluations in Support of SC-228 MOPS Development

At the May 2015 SC-228 meeting, requirements for TCAS II interoperability became elevated in priority. A TCAS interoperability work group was formed to identify and address key issuesquestions. The TCAS work group 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 displayalertingguidance 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.

detect and avoid↗

International Coordination and Cooperation on LunaNet Spectrum

LunaNet is planned to be the network of networks operated by a set of cooperating organizations to provide interoperable Communications, networking, Position, Navigation, and Timing (CPNT) services to users on and around the Moon based on a framework of mutually agreed-upon standards, protocols, frequency bands and interface requirements. LunaNet follows a service-oriented architecture that is agnostic about the types of organizations that provide services, e.g., government, industry, or academia. LunaNet is open, scalable, resilient, secure, and extensible. To achieve these goals, LunaNet Service Providers (LNSP) must coordinate with each other to define and develop the architecture, to plan initial and evolved capabilities, and to operate their networks. One of the central LunaNet tenets is the use of shared spectrum. For example, the Lunar Augmented Navigation Service (LANS) acts like a Global Navigation Satellite System (GNSS) such as the US Global Positioning System (GPS) or European Galileo but the LNSPs’ contributions to LunaNet must use the same frequency band (2483.5 MHz-2500.0 MHz) and transmit the same waveform synchronized by highly accurate clocks so that Users ‘see’ one virtual network and use the same multilateration algorithm to determine their positions. This necessitates a high degree of spectrum coordination. NASA’s Lunar and Human Spaceflight Spectrum Management Team has been actively supporting development of the LunaNet Interoperability Specification (LNIS), soliciting inputs from spectrum policy and planning experts across NASA, ESA and JAXA. Cislunar spectrum use considerations have been studied and adjudicated within the Space Frequency Coordination Group (SFCG) and inform the ongoing discussion of a lunar communication and navigation architecture within the existing radio regulatory framework of the International Telecommunication Union, leading to the 2027 World Radiocommunication Conference (WRC-27). The frequency plan contained in the publicly released draft of the LunaNet Interoperability Specification reflects the initial phase of exploration (roughly to 2030) defining an optimal set of radio frequencies in appropriately allocated services consistent with WRC-23 decisions for use by known or planned CPNT applications, while striving to maximize coexistence and compatibility amongst cislunar systems and other systems within the near-Earth regime (< 2 million km from Earth). Important considerations include: protection of extremely sensitive receive-only radio astronomy systems on the lunar far side, known as the Shielded Zone of the Moon (SZM); compatibility between Direct with Earth (DWE) communications links and links needed to support relay satellites in lunar orbit with their customer systems on orbit or on the lunar surface; compatibility between multiple lunar surface communications systems and capabilities over varied and challenging terrain and distances; as well as ensuring compatibility and interoperability between navigation systems which either leverage Earth-based or in-situ lunar systems. In addition, the lunar CPNT architecture is envisioned to be the basis – with adjustments – of the future Mars CPNT architecture as we expand into the solar system using Interplanetary Networking (IPN). The second phase of lunar spectrum definition will address planned international capabilities for the next decade that will require action at WRC-27 and beyond. This paper will discuss each of these considerations in more depth and how the current LunaNet frequency plan addresses them.

LunaNet↗

Multi-language Struct Support in Babel

Babel is an open-source language interoperability framework tailored to the needs of high-performance scientific computing. As an integral element of the Common Component Architecture (CCA) it is used in a wide range of research projects. In this paper we describe how we extended Babel to support interoperable tuple data types (structs). Structs are a common idiom in scientific APIs; they are an efficient way to pass tuples of nonuniform data between functions, and are supported natively by most programming languages. Using our extended version of Babel, developers of scientific code can now pass structs as arguments between functions implemented in any of the supported languages. In C, C++ and Fortran 2003, structs can be passed without the overhead of data marshaling or copying, providing language interoperability at minimal cost. Other supported languages are Fortran 77, Fortran 90, Java and Python. We will show how we designed a struct implementation that is interoperable with all of the supported languages and present benchmark data compare the performance of all language bindings, highlighting the differences between languages that offer native struct support and an object-oriented interface with getter/setter methods.

97 MATHEMATICS AND COMPUTING↗

Guide to Developing Energy Services Interfaces

This document provides guidance to develop communications interfaces that are highly interoperable and adhere to a set of energy services interface (ESI) principles. It can be applied in the context of information and communications technology interface standards and implementation profiles that enable the integration of a facility with responsive distributed energy resources (DER) into an electric power system consistent with the fundamental ESI principles. In this context, a DER facility may consist of a single DER with a communicating controller or may be as complex as a microgrid campus with several buildings and many DERs. This document is not a technical interface standard, but the requirements described can be used to check that existing, augmented, or new interface standards meet the interoperability requirements of the ESI concept. In this way, this guide for the ESI specification can support future advancements in developing interoperability standards and implementation profiles. The intended audience for this document is DER integration practitioners and ecosystem groups that are in the business of developing and implementing communications interfaces for DER integration. It is intended that these groups apply the information and processes in this document to develop communications standards and implementation profiles that are consistent with fundamental ESI principles.

2030.5↗

Use of Hardware-in-the-Loop to De-Risk Field Deployment of Hydrogen Assets

Grid-forming assets are required in microgrids to act as voltage-frequency masters. These grid-forming assets can operate in two modes of operation: grid-following mode and grid-forming mode. In grid-following mode of operation, these assets will follow real power and reactive power setpoints and in grid-forming mode of operation these assets will follow voltage and frequency setpoints. Traditionally, diesel generators or natural gas-based generators are widely used to act as a voltage-frequency master. However, many utilities are aiming to replace generators with grid forming-inverters supplied by solar photovoltaics (PV), batteries or fuel cells. Since grid-forming assets need a long-term reliable energy source, fuel cells are a reasonable and viable choice to supply the grid-forming inverters, but some of the challenges facing the wide deployment of grid-forming fuel cell inverters need to be addressed. Specifically, in our proposed work, we aim to focus on the interconnection and interoperability requirements of grid-forming fuel cell inverters. Currently, state-of-the-art fuel cell inverters follow the general interconnection requirements of distributed energy resources (DERs) and general interoperability requirements of DERs, but these requirements were built with PV and battery systems in mind. Fuel cells have different operational requirements, and therefore these requirements need to be appropriately modified for the grid operators to use. These additional steps add to the investment and operational cost to the grid operators. Through the ARIES platform, this proposed project aims to bridge this gap and use power hardware-in-the-loop (PHIL) and controller hardware-in-the-loop (CHIL) experiments to inform the creation of open-source interconnection and interoperability information that can aid in faster and cheaper installation and operation of grid-forming fuel cell inverters.

08 HYDROGEN↗

Aligning NASA Earth Science Data Stewardship with FAIR Principles: Outcomes, Recommendations, and Future Directions

The FAIR Principles—Findable, Accessible, Interoperable, and Reusable—offer a widely accepted framework for improving the sharing and reuse of digital scientific data by both human and machine users. Following these principles is critical for effective scientific data stewardship, broader scientific collaboration, and compliance with federal and agency data policies. This paper, based on the work of NASA’s Open, Free, and FAIR Working Group (O’FAIR WG) under the Earth Science Data Systems Program, presents an overview of how FAIR is being applied within NASA’s Earth science data landscape. It highlights ongoing progress and challenges, identifies FAIR-enabling resources, and offers recommendations and strategic actions to enhance the FAIRness of NASA-funded open and free Earth science data products. The FAIR-enabling resources identified underscore the vital role of NASA's existing enterprise processes, standards, tools, and infrastructures in supporting FAIR implementation. Our findings show strong performance in making NASA Earth science data more findable and accessible. However, further work is needed—especially in enhancing interoperability, so that different systems and tools can better understand and exchange data. This is especially important for enabling machine-driven discovery and analysis. We emphasize the importance of a balanced strategy that combines a centralized, top-down approach—focused on building enterprise-level capabilities and processes—with a decentralized, bottom-up approach driven by discipline-specific needs and community practices. We advocate for coordinated efforts to enhance (meta)data interoperability to facilitate seamless data and information sharing and exchange of Earth science data both within NASA and across other agencies managing Earth science data.

Data Product↗

Evolving the SpaceFOM: Lessons Learned and Future Development

For over fifty years, simulation has been a cornerstone technology for space missions. In many cases, one single simulator, developed by one team, is not enough to meet the simulation objectives. Astronaut crew training, docking, vehicle testing and complex mission planning all require several simulations to be connected and to interoperate, in order to achieve the goal of the simulation. To facilitate the development of interoperable simulations, an open standard, the SISO SpaceFOM was developed in collaboration between government, industry and academia. The standard was released in 2020. The initial release of SpaceFOM focuses on the core interoperability topics for space simulation: (i) specifying spatial data using several, well defined reference frames, (ii) managing time (including real-time, hard real-time, and as-fast-as-possible execution), (iii) composition of systems with subsystems such as space vehicles, and (iv) execution control, such as initializing, running, pausing, and terminating simulations. A number of requirements for the next version of SpaceFOM have been identified and proposed solutions are already under development. One key area is the object classes used for data exchange, where a richer set of classes have been proposed, based on practical use cases. For time management, the use of variable time resolutions and variable time steps is also proposed. For execution control, save and restore of simulations is considered as well as improved robustness, to handle failing components. A number of clarifications are also under consideration. This paper provides both a forward-looking view of the technical developments underway and a retrospective on the standard's evolution. The authors emphasize that prioritizing core challenges and delivering a practical first version were crucial steps. While not every idea was implemented in the initial release, the timely delivery of a functional standard enabled real-world applications, the growth of a user community, and the collection of valuable insights to shape future versions. The authors look forward to working with the next version of SpaceFOM together with the growing user community.

FOMs↗

Improving and Automating Building Model Data Exchange

There are many instances throughout a project’s lifecycle where there arises a need for quick and accurate risk assessment of building designs. For example, an unexpected design change during construction may necessitate structural engineers to perform a seismic risk assessment on analytical models of the updated building design using high fidelity structural analysis software, such as ANSYS or Abaqus. However, the efficiency of such workflows often depends upon the interoperability of architectural design software and structural analysis software. When the quality of this interoperability is lacking or even non-existent, the efficiency of virtual engineering workflows is hampered, which increases project costs. A McGraw Hill industry survey of professional users of Building Information Modeling (BIM) technologies found that there is high demand for BIM interoperability for structural analysis, but that the value/difficulty ratio is currently too low for practical use. There have been efforts by the academic community to facilitate model data exchange between the architectural design and structural analysis domains, but such solutions have not been widely adopted by industry, face technical challenges, and oftentimes are limited in applicability for users of various BIM software. Therefore, INL is developing capabilities to improve, automate, and generalize model data exchange between architectural BIM software (e.g., Revit) and structural analysis software (e.g., SAP2000, ANSYS). The goal is to help expedite and automate as much of the pre-processing step for creating analytical models in finite element analysis software as reasonably as possible. Such a "BIM-to-FEA" conversion tool should provide direct benefit to end-users through accuracy, automation, quick turn-around, and wide applicability. To generalize the application of this BIM-to-FEA conversion tool and increase its useability among the many different commercial BIM software currently used by industry, the program is being developed with the concept of openBIM. OpenBIM is the application of non-proprietary, open data standards that allow for BIM model data exchange in a format that is accessible, retainable, and useable for all users. The most widely used open, non-proprietary data exchange format for BIM is the Industry Foundation Classes (IFC) schema. IFC is developed by buildingSMART international and is ISO certified (ISO 16739-1:2018). The BIM-to-FEA conversion tool is being developed for compatibility with typical commercial building designs of steel framed structures. The tool is currently capable of importing architectural BIM data of framed building structures, recognizing and extracting the aspects of the model that are required for structural analysis, adjusting the connectivity of frame members, and finally exporting to an analytical model stored in the IFC format. The exported IFC analytical model can then be imported into various openBIM compliant software, such as SAP2000. Such capabilities have already been tested on commercial software, as shown above, and continue to be improved. Work is underway to test the conversion on various commercial BIM software, develop a user-friendly interface, incorporate the program into the broader DeepLynx data warehouse project being developed by INL, and to eventually open-source the tool for the benefit of the community. Future development of the tool envisions the ability for efficient iterative risk assessment of generative building designs, all within a workflow utilizing open-source tools. One such open-source tool will be MOOSE, an advanced finite element analysis tool developed at INL. The conversion tool will also branch out from typical commercial building designs and will aim to incorporate nuclear construction. The aim will be to convert both structural and non-structural components of nuclear facilities, such as curved concrete containment structures and piping systems, respectively.

97 MATHEMATICS AND COMPUTING↗

An overview of data tools for representing and managing building information and performance data

Building information modeling (BIM) has been widely adopted for representing and exchanging building data across disciplines during building design and construction. However, BIM's use in the building operation phase is limited. With the increasing deployment of low-cost sensors and meters, as well as affordable digital storage and computing technologies, growing volumes of data have been collected from buildings, their energy services systems, and occupants. Such data are crucial to help decision makers understand what, how, and when energy is consumed in buildings—a critical step to improving building performance for energy efficiency, demand flexibility, and resilience. However, practical analyses and use of the collected data are very limited due to various reasons, including poor data quality, ad-hoc representation of data, and lack of data science skills. To unlock value from building data, there is a strong need for a toolchain to curate and represent building information and performance data in common standardized terminologies and schemas, to enable interoperability between tools and applications. This study selected and reviewed 24 data tools based on common use cases of data across the building life cycle, from design to construction, commissioning, operation, and retrofits. The selected data tools are grouped into three categories: (1) data dictionary or terminology, (2) data ontology and schemas, and (3) data platforms. The data are grouped into ten typologies covering most types of data collected in buildings. This study resulted in five main findings: (1) most data representation tools can represent their intended data typologies well, such as Green Button for smart meter data and Brick schema for metadata of sensors in buildings and HVAC systems, but none of the tools cover all ten types of data; (2) there is a need for data schemas to represent the basis of design data and metadata of occupant data; (3) standard terminologies such as those defined in BEDES are only adopted in a few data tools; (4) integrating data across various stages in the building life cycle remains a challenge; and (5) most data tools were developed and maintained by different parties for different purposes, their flexibility and interoperability can be improved to support broader use cases. Finally, recommendations for future research on building data tools are provided for the data and buildings community based on the FAIR principles to make data Findable, Accessible, Interoperable, and Reusable.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

Experimental Characterization Test of a Grid-Forming Inverter for Microgrid Applications

Standardized experimental testing protocols for grid forming (GFM) inverters to ensure expected operation under both normal and contingency conditions do not exist. Such protocols increase the confidence of system owner/operators that an inverter deployed in a proposed system will engage in typical behaviors to ensure interoperability with other units and ancillary equipment (e.g. protection equipment). This paper presents systematic and comprehensive test protocols to evaluate the performance of GFM inverters under the following operational configurations: islanded operation, heterogeneous islanded operation (parallel with a synchronous generator), grid-connected operation, and transition operation. A commercial GFM inverter is used to verify the test protocols and to understand the inverter's performance and functionalities. In particular, required configuration and tuning of the inverter will be explained in the full paper to enrich the testing protocol.

black start↗

Development and Experimental Validation of a High-Power DC Distribution Testbed for Advanced Charging Infrastructure and Energy Management

This paper presents the development of a hardware testbed for DC-distributed high-power charging (HPC) stations. As DC distributed solutions emerge as a viable solution to optimize HPC site operations, challenges such as interoperability, protection, and seamless integration of distributed energy resources (DER) persist. These issues underscore the need for a robust testing facility to investigate compliance of available commercial off-the-shelf (COTS) market devices. The developed testbed features a DC-distributed charging hub including a charger, emulated energy storage system (ESS), and site level communication and controller implementation. It facilitates the testing of COTS hardware, charger prototypes, standards validation and site energy management system (SEMS) controllers at rated power. This paper details the development of the charging infrastructure platform, implementation of communication system, validation of different SEMS algorithms, and understanding improvements required for future expansion. Using the developed testbed, interoperability gaps for SEMS implementation with multi-vehicle concurrent charging via a multi-port charger are experimentally observed. Aimed at supporting the transition to large-scale EV charging infrastructure deployment and DER integration, this testbed plays a crucial role in conformity testing of COTS device interoperability.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Summary Report for the Environmental Protection Agency MERL/FRMAC Mission Alignment Exercise held at the Environmental Protection Agency Facility on June 24-26 2014

From June 24th thru June 26th 2014, members of the Federal Radiological Monitoring and Assessment Center (FRMAC), FRMAC Fly Away Laboratory, and the Environmental Protection Agency (EPA) participated in a joint nuclear incident emergency response/round robin exercise at the EPA facility in Las Vegas, Nevada. The purpose of this exercise was to strengthen the interoperability relationship between the FRMAC Fly Away Laboratory (FAL) and the EPA Mobile Environmental Radiation Laboratory (MERL) stationed in Las Vegas, Nevada. The exercise was designed to allow for immediate delivery of pre-staged, spiked samples to the EPA MERL and the FAL for sample preparation and radiological analysis. Upon completion of laboratory analysis, data was reviewed and submitted back to the FRMAC via an electronic data deliverable (EDD). In order to conduct a laboratory inter-comparison study, samples were then traded between the two laboratories and re-counted. As part of the exercise, an evaluation was conducted to identify gaps and potential areas for improvements for FRMAC, FAL and EPA operations. Additionally, noteworthy practices and potential future areas of interoperability opportunities between the FRMAC, FAL and EPA were acknowledged. The exercise also provided a unique opportunity for FRMAC personnel to observe EPA sample receipt and sample preparation processes and to gain familiarity with the MERL laboratory instrumentation and radiation detection capabilities. The areas for potential improvements and interoperability from this exercise will be critical for developing a more efficient, integrated response for future interactions between the FRMAC and EPA MERL assets.

54 ENVIRONMENTAL SCIENCES↗

Warthog: A MOOSE-Based Application for the Direct Code Coupling of BISON and PROTEUS

The Nuclear Energy Advanced Modeling and Simulation (NEAMS) program from the Department of Energy's Office of Nuclear Energy provides a robust toolkit for the modeling and simulation of current and future advanced nuclear reactor designs. This toolkit provides these technologies organized across product lines: two divisions targeted at fuels and end-to-end reactor modeling, and a third for integration, coupling, and high-level workflow management. The Fuels Product Line and the Reactor Product line provide advanced computational technologies that serve each respective field well, however, their current lack of integration presents a major impediment to future improvements of simulation solution fidelity. There is a desire for the capability to mix and match tools across Product Lines in an effort to utilize the best from both to improve NEAMS modeling and simulation technologies. This report details a new effort to provide this Product Line interoperability through the development of a new application called Warthog. This application couples the BISON Fuel Performance application from the Fuels Product Line and the PROTEUS Core Neutronics application from the Reactors Product Line in an effort to utilize the best from all parts of the NEAMS toolkit and improve overall solution fidelity of nuclear fuel simulations. To achieve this, Warthog leverages as much prior work from the NEAMS program as possible, and in doing so, enables interoperability between the disparate MOOSE and SHARP frameworks, and the libMesh and MOAB mesh data formats. This report describes this work in full. We begin with a detailed look at the individual NEAMS framework technologies used and developed in the various Product Lines, and the current status of their interoperability. We then introduce the Warthog application: its overall architecture and the ways it leverages the best existing tools from across the NEAMS toolkit to enable BISON-PROTEUS integration. Furthermore, we show how Warthog leverages a tool known as DataTransferKit to seamlessly enable the transfer for solution data between disparate frameworks and mesh formats. To end, we demonstrate tests for the direct software coupling of BISON and PROTEUS using Warthog, and discuss current impediments and solutions to the construction of physically realistic input models for this coupled BISON-PROTEUS system.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

An Open Source Extensible Smart Energy Framework

Aggregated distributed energy resources are the subject of much interest in the energy industry and are expected to play an important role in meeting our future energy needs by changing how we use, distribute and generate electricity. This energy future includes an increased amount of energy from renewable resources, load management techniques to improve resiliency and reliability, and distributed energy storage and generation capabilities that can be managed to meet the needs of the grid as well as individual customers. These energy assets are commonly referred to as Distributed Energy Resources (DER). DERs rely on a means to communicate information between an energy provider and multitudes of devices. Today DER control systems are typically vendor-specific, using custom hardware and software solutions. As a result, customers are locked into communication transport protocols, applications, tools, and data formats. Today’s systems are often difficult to extend to meet new application requirements, resulting in stranded assets when business requirements or energy management models evolve. By partnering with industry advisors and researchers, an implementation DER research platform was developed called the Smart Energy Framework (SEF). The hypothesis of this research was that an open source Internet of Things (IoT) framework could play a role in creating a commodity-based eco-system for DER assets that would reduce costs and provide interoperable products. SEF is based on the AllJoynTM IoT open source framework. The demonstration system incorporated DER assets, specifically batteries and smart water heaters. To verify the behavior of the distributed system, models of water heaters and batteries were also developed. An IoT interface for communicating between the assets and a control server was defined. This interface supports a series of “events” and telemetry reporting, similar to those defined by current smart grid communication standards. The results of this effort demonstrated the feasibility and application potential of using IoT frameworks for the creation of commodity-based DER systems. All of the identified commodity-based system requirements were met by the AllJoyn framework. By having commodity solutions, small vendors can enter the market and the cost of implementation for all parties is reduced. Utilities and aggregators can choose from multiple interoperable products reducing the risk of stranded assets. Based on this research it is recommended that interfaces based on existing smart grid communication protocol standards be created for these emerging IoT frameworks. These interfaces should be standardized as part of the IoT framework allowing for interoperability testing and certification. Similarly, IoT frameworks are introducing application level security. This type of security is needed for protecting application and platforms and will be important moving forward. Recommendations are that along with DER-based data model interfaces, platform and application security requirements also be prescribed when IoT devices support DER applications.

25 ENERGY STORAGE↗

Hamilton: Flexible, Open Source $10 Wireless Sensor System for Energy Efficient Building Operation

Sensors for improving building performance are rapidly populating the market, driven in part by the drive to reduce greenhouse gas emissions resulting from energy production as well as improve the interior environment for healthy and more productive spaces. UC Berkeley has led wireless sensor development over the past 25 years (e.g., Telos mote), with the Hamilton (named after Alexander Hamilton on the US $10 bill) as the most recent. The Hamilton sensor was designed as a low-cost high-performance sensor that is modular and interoperable. The objective of the Hamilton project was to create, evaluate and establish the technological foundations for secure and easy to deploy building energy efficiency applications utilizing pervasive, low-cost wireless sensors integrated with traditional Building Management Systems (BMS), consumer-sector building components, and powerful data analytics. The project included iterative hardware design, incorporating a high-performance database (BTrDb, http://btrdb.io/), creating and iterating the development of secure data middleware (BOSSwave, WAVE/WAVEMQ), working with and pushing the development of an open-source tiny operating system RiotOS, and implementing and improving protocols such as Thread/OpenThread and TCP/IP. The hardware benefited from careful design to drive down the cost; the design included a System-on-a-Chip (SoC), chip antenna, single crystal and five passive components. Careful design of the operating system created a low-power design to enable a long life with small batteries. The hardware included several sensors: temperature, radiant temperature, relative humidity, magnetometer, accelerometer, and light, with an optional occupancy (Passive InfraRed) sensor. The project was the basis of several applications, both internal to the research team and other researchers and professionals at other institutions. Several applications used the sensor hardware as the basis for other complex devices. Other applications used the sensors to improve building performance through interoperating with the building Heating Ventilation and Air-Conditioning (HVAC) system, such as using occupancy and/or distributed temperature sensing to reduce HVAC zone energy while still providing thermal comfort and to reduce peak loads in small commercial buildings. We demonstrated cloud-based energy analytics, implemented a schedule and a Model Predictive Controller in a small commercial building to optimize HVAC energy, occupancy and electricity price. Initial integration of these technological innovations was performed through the creation of execution containers containing the WAVE agent and various driver, proxy, or building system function logic. The research added to the understanding of efficient sensor hardware, secure middleware, time-series data management (high performance database), efficient communication protocols, and interoperating with applications and building systems. The project showed the technical effectiveness and economic feasibility of creating a low-cost, modular, and easy-to-deploy sensor. Through conversations with multiple end users, the research team discovered that many customers wanted data management and services in addition to the sensors. HamiltonIOT developed packages of sensors, border router, and data services to provide a seamless “plug-and-play” sensor deployment. Some customers were willing to pay for higher quality sensors (such as light); some customers wanted a robust enclosure (waterproof).

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗