Below is the text version of the webinar Connected Buildings Interoperability Vision, presented in May 2015.

Steve Widergren:
Presentation cover slide:
... the webinar that we have for you today on Connected Buildings Interoperability Vision. I wanted -- My name is Steve Widergren. I'm with Pacific Northwest National Laboratory. I'm going to give the floor here to Kevin Lynn in just a moment. I wanted to let everybody know that the webinar is being recorded. So any of your colleagues who can't make it today will be able to listen to this at another time. Also, we will try to have time for a Q and A period at the end. So please type your questions in. There's a chat window and a question window. You want to type your question into the questions section there. And we will review those and try to get them at the end of the meeting. If you do have a clarifying question, we'll try to be monitoring that, too, and answer it as it comes up, just so we make sure that we're communicating properly and not leaving you confused out there. So, with that, I'm going to turn the floor over to Kevin Lynn, who is the director of grid integration at EERE at the U.S. Department of Energy. Kevin, lead us off.

Kevin Lynn:
Thanks, Steve. I'm really looking forward to this webinar. I'm going to kick us off at about regarding connected buildings and interoperability and its connection to our broader grid modernization initiative over the next few minutes. I just wanted to provide some context about how this effort fits into the broader DOE effort within grid modernization. So next slide.

Next slide:
So within EERE, you know, specifically, about the Office of Energy Efficiency and Renewable Energy, our mission is to enhance energy efficiency and productivity to bring clean and reliable, affordable energy technologies to the marketplace and to make a difference in the everyday lives of Americans by enhancing energy choices and their quality of life. EERE has spent around $17 billion of Recovery Act funds to stimulate jobs and create a clean energy economy in the U.S. So next slide.

Next slide:
So let me talk a little bit more broadly about our grid modernization initiative. So grid modernization is a cross-cutting initiative across the Department, mainly including the Office of Energy Efficiency and Renewable Energy, the Office of Electricity, and Energy Policy and Systems Analysis office. So basically we're trying as part of this initiative to integrate all of the grid modernization efforts that we have across the Department into an integrated, single focus. And part of the next couple slides is talking about that broader focus and how this interoperability webinar fits into that.

Next slide:
So part of the broader grid modernization vision. The future grid provides a critical platform for U.S. prosperity, competitiveness, and innovation in a global clean economy. Must deliver reliable, affordable, and clean electricity to consumers where, when, and how they want it. And we see these three blue boxes as basically focusing on where exactly the focus is. It's basically focusing on enhancing security for the nation, both cyber and physical security, trying to sustain economic growth and innovation, so enabling new technologies to come onto the grid. And to achieve many of our public policy objectives, whether it's integrating clean electricity into the grid or meeting RPS goals or energy efficiency policy standards, and meeting some of our climate adaption and resilience.

Next slide:
So that's our vision for this. Part 1, I think, is different in this particular activity or initiative, as opposed to how we've done things in the past, because we're actually looking across different offices and trying to balance a variety of things all at the same time. So we're not necessarily focusing just on clean or reliable or flexible or affordable at any time. We're trying to balance a variety of these attributes that you see here on this slide. So we're trying to balance reliable, affordable, clean electricity, flexible, and innovative all at the same time and trying to do it in a regional fashion, as well. So that's something that's different about what we're trying to do here. Next slide.

Next slide:
So as part of our national goals and outcomes, as part of this broader effort, we're trying to accomplish three major national outcomes by 2025. Try to reduce the economic cost of power outages by 10 percent. We're trying to reduce the reserve margins by about a third by 2025. And we're trying to decrease the net integration cost of distributed energy resources by about 15 percent. And we think if we can achieve these national outcomes over the next 10 years, that will save about, on average, about $7 billion to the U.S. economy every year. And in addition, it will enable a variety of new technologies to be able to integrate in a plug-and-play fashion in a way that hasn't been done, and it's basically bringing us into a 21st century or modernized grid. Next slide.

Next slide:
So these are the six technical areas that we've developed a multiyear program plan to address -- try to reach those three national outcomes. And we're basically addressing these in the six technical areas. So sensing and measurement, devices and integrated systems, system operation and power flow, design and planning tools, security and resilience, and institutional support. So all of these different -- these six activities basically all of our activities in grid modernization across the Department can fit into one of these six technical areas that are outlined in our multiyear program plan. Next slide.

Next slide:
So how does the connected building fit into that? So this fits very well into basically our devices and integrated systems testing and our sensing and measurement areas. So the nice thing about the connected building is it's sort of going into a foray into trying to basically transact energy services across the earth utilizing an entirely new set of technologies or end use devices that we haven't been using to provide value to the grid. And enabling those technologies to help provide some services to the grid. So we're very excited about being able to reach out from the Building Technologies Office specifically, and being able to utilize all these different technologies to enable those three national goals that we talked about previously. Next slide.

Next slide:
So, I mean, clearly why, you know, some of the reasons we need connected buildings. Basically, trying to enable clean energy technologies to be integrated into the system, you know, enabling ancillary services, enabling, being able to -- for the systems to be grid-responsive, building technologies to be integrated in the system. And interoperability is a DOE broadly huge priority for us across the entire Department. And we're really excited to have the Building Technologies Office working across with all the other different departments here to really take the lead in terms of developing some of these interoperability standards for building information and exchange.

Next slide:
So with that, I'm going to turn things over to Steve Widergren and talk more about, specifically about the connected buildings interoperability vision. Steve, take it away. ... Steve, are you there?

Steve Widergren:
I am sorry. There we go. Sorry about that. Thank-you very much, Kevin, for leading us off on this. In my work here at PNNL, I have been working in the grid space on integration issues and interoperability for quite some time. It's an honor to be working with the Buildings group here and looking at buildings as a resource for the grid, but also as a resource amongst Buildings and with other players involved. So that's what we've been tackling with the interoperability concerns, and putting together a vision, working on the vision statement for this area.

Next slide:
So I'm going to go over in about, let's see, the next 40 minutes here, or 35 or 40 minutes, so that we have time for Q and A: Some context for our interoperability activities. And then what I'm going to talk briefly about: a national strategy for buildings interoperability, basically, our project strategy and steps for aligning buildings automation community on interoperability, and then really the sort of main focus for this whole webinar is the connected buildings interoperability vision technical meeting that we held in March, and some reports on that. The good information that we received from that session.

Next slide:
Just to kind of provide some more context here for this work. The types of scenarios that we're looking at for interoperability. I'm giving two examples; I'm not going to go into details of these. But you can imagine, diagnostics, automated commissioning services of buildings, the fact that the information that is retained within smart devices or those that have computer technology and intelligence located with them, that they could actually announce and provide status and information about their operation, and do this in some sort of standard way that could be accessed by third parties, perhaps to look at the performance of a building and do things like continual commissioning type services.

Next slide:
So the various ICT standards and all that would go into being able to connect -- having these things connect and provide the appropriate information to support that type of application. Another example would be -- imagine in a fairly complex building where you have a building owner that has multiple tenants involved with it. They have an allocation for the energy bill. If they exceed their allocation, they could have penalties or they could be having things like dynamic rates broadcast to them, basically using markets to try to balance the energy consumption within the building and levelize some things so that at the more expensive times, the total building load is reduced and more at the cheaper times it was increased. So that would require this sort of coordination amongst the various tenants within the building to be able to enact the appropriate responses to the system. And all -- imagining all the connections that need to take place for that, and the information exchange to make that happen, are a couple of examples of -- by the way, there is a document that was put out here, referenced down at the bottom here, Transaction-Based Building Controls Framework Reference Guide, which you can find on the Energy.gov website. The previous slide had a link to that document.

Next slide:
So what do I mean by interoperability? And I tie interoperability very closely with integration. It's trying to integrate things but let's do it more at arm's length. Let's make this easy, and simple. Let's, if we could, we would sort of get rid of the integrator's job. But I don't know that we could -- that's in many cases a very difficult thing to achieve. But those are the sort of goals and things that we want to -- objectives that we want to get at with interoperability, making things connect and work simply.

Next slide:
So by that, it's this exchange of actionable information between two or more systems. There's a little post box here: If you understand, when you put a letter in a mail, how it gets to the other person through the magic of the U.S. mail system. And on the other side, we're able to unpack it. We're able to read it, because we have certain conventions that we use within our society that allow that transaction to take place.

Next slide:
So we have to have -- within that letter, we have to understand the shared meaning of the information, and we have to have -- when we're asked to do something, we need to have some sort of agreed expectation with consequences associated with that, sort of more or less like a contract. Some of those are social contracts that we make; others are more rigid types of contracts. In order for this to all work, we have to have a certain level of performance for this system. So that includes civil liability of that communication, the fidelity of the information, security of it, things like privacy, and all those need to be taken care of in order for all of this to -- this transaction to take place.

Next slide:
If we could do that, if we can reduce that integration effort, if we could make things more reliable, we have many different benefits, which accrue to the process. So reducing integration cost, operations cost, capital costs, more choices in products, and different price points and features. If we understand how these systems connect and can operate together. Now, we often focus on the technical layers in interoperability, so we have some communication standards and networking standards, things like protocols that are there. But again, it's not just good enough to get the letter to the destination. You need to unpack it. You need to understand the contents of that letter. And those contents need to fit within some sort of organizational or human processes that are involved in there. So there's business processes. There's policies. There's even laws and things that we operate under in order for that full transaction to take place in a more seamless manner.

Next slide:
I like to use this next slide here. This is from Scott Newman, who participated in a Gridwise Architecture Council meeting many moons ago now. But he likened the interoperability issue to something which is really trying to reduce this distance to integrate. And you can imagine the first time that you're in a project with communications technologies; you're trying to get systems to work together. Those standards exist. You've spent a fair amount of time, probably many more hours and weeks than you imagined or budgeted for, to get that integration to occur. When you have some interfaces that get well-defined, and you're able to transform or map them together, you can reduce that time to integrate. And if you have things like common models or common information models with which semantics, so to speak, are aligned, that time is reduced. And eventually, you can either get down to or very close to the type of plug-and-play standards that we would like to see systems come together as. Now, it may not be always cost-effective to get to the plug-and-play point, depending upon how complex this integration really is, but you can see, you don't have to necessarily get there. You can have savings just by taking steps in the right direction.

Next slide:
Interoperability from just kind of a broader area. We often focus on these interfaces for interoperability, things like discovery, the building automation products that were out there, and the services, how to interact with them, their characteristics, and how they could discover and interact with other building systems. These are all part of specifications and interface standards that are out there. But really, for interoperability to achieve interoperability, we need to put some sort of trust mechanism in there. And so testing and certification of products becomes important, so that when the buyer goes out and acquires and invests in this equipment, that they have a level of assurity that it is really going to work and perform like they intended. And in order for that to happen, in order to have and support these testing and certification type systems, and to have a set of interoperable products, we need a market ecosystem behind that. And so that is companies coming together, you know, making and supporting standards, and also other things. Not necessarily just a technical standard, but it could be other sorts of conventions that are needed to make those products connect and operate simply.

Next slide:
So as a part of the project that we've been working on here, we started with -- we needed to -- we felt we needed to come up with the state of buildings interoperability today. And so we created a landscape document. It's draft form. This slide has a link at the bottom of it. And at the end of this presentation, that you can put on, we definitely want your need to review it and provide us comments to that. And I've given my contact information at the end of the slides here. But this particular document goes over and provides a framework for interoperability. It talks about classes of use cases, or basically the scenarios in which -- in applications that would be supported by interoperability. And relevant standards that are out there today, a taxonomy of stakeholders that are involved. It also looks at some goals for interoperability and puts forth, arguably, some areas that could be the start of requirements for interoperability. How do we know that we have interoperability? And some challenges and gaps, as well as talking about some newer standards that are looking at emerging interoperability areas that are going to be important for moving forward in this area.

Next slide:
In terms of developing the framework, we based that on a number of things that have been going on over the years. Base ASHRAE work, things done within what is the Smart Grid Interoperability Panel, the Gridwise Architecture Council. And some work done in Europe, which actually tried to marry all these things together.

Next slide:
And so we've come up with this three-dimensional model as a framework to try to discuss some of these issues. It turns out it's very difficult to paint pictures in three dimensions on a flat surface. But I think conceptually, we can uphold about three things in our mind here. In this case, we have on the vertical axis technical, informational, and organizational layers of interoperability. On the horizontal axis, we have the players that are involved, the actor domains. So we have building operators, building communities for communicating between buildings, communicating with building service providers, third parties, etcetera. Market service providers, so looking at things like energy or water or other sorts of markets that might be out there. And then those that distribute and actually have the products like electricity that are delivered to a building. And then on the going into the point in here, the Z axis, we have the Purdue Model. This is actually a version of that, that was standardized out of ASHRAE that looks at, down at the local control device level, the controlling of that device, application-specific. And then supervisory level, getting more systems of systems within the building. And then the overall management, which is looking at the business of the building and maybe a series of buildings that are out there as part of an enterprise.

Next slide:
So just an example of using this framework. We've taken what was the vertical axis in the previous slide, the interoperability layers of technical, informational, and organizational, and the device control supervisory management levels, and mapped out roughly -- this is not a science, but more of an art -- in terms of the standards that are out there today. And so we see a lot in this lower left-hand corner. A number of standards out there that are very device-oriented and technically oriented. They do go into the control space a bit. And then we have a few that go into the control and supervisory level. Their information models are very -- tend to be very lightweight. They're very point-oriented. They're things like where you have to use naming conventions rather than a rich semantic understanding like one might find in an ontology or something like that in the computer science world. And then some of them work at the higher levels here. But again, this is an example of how we could maybe look at the framework, see that there's a lot going on in the technical side, not so much going on informationally, and pretty much nothing organizationally.

Next slide:
And that's reflected in some of these gaps and challenges. I don't have the time to go through all of these. These are listed within the document, and we've got some new ones based on the technical meeting that we held in March. But for example, at the organizational level, we could pretty much say that the state of standards making has not encompassed the business processes aligned with business objectives. It's more the technical little bit of the information level. And at the information level, we've got models that are very generic. They're point data / value type pairs that are listed in these data structures. There's no rich equipment models behind them in an operational sense. Probably the richest type of models are more in architectural type systems, which are actually designing the building. But they don't get into the operations space, so far at this point. And then at the technology level, well, we have a lot of communication standards, a lot of protocols intact, types of things. And the issue there is there's such a wide variety of them. The difficulty in supporting all of them are which ones should you support.

Next slide:
Looking at things like -- we also looked at things like configuration and evolution capabilities. Things like resource discovery. Is it general / not supported? I mean, there are some standards out there, but most of it relies on maintenance setup. Operation and performance is often not scalable, so there tends to be unclear separation between communication medium and messaging standards. And some of that is changing with newer versions of the standard, which is good to see. But more work needs to be done there. And then on the security, privacy, and safety side, that's often an afterthought. So particularly looking at safety systemic failures, when we get above the device level and into more supervisory level, you know, what sort of fail-safe mechanisms are being done in any sort of standard fashion, in terms of the interaction of these compounds.

Next slide:
So the document also goes into -- asks this question: Can we measure interoperability? And there was some work done by the Gridwise Architecture Council on an interoperability maturity model, based on some work out of the capability maturity model for integration out of the Carnegie Mellon SEI Institute. And so the idea here is if we want to improve interoperability, how can we even measure what's out there? So that particular document looks at organizational goals, things like compatible business processes that exist across interface bounding, informational goals, is there an information model that's relevant to that context, and configuration and evolution goals. An example of that would be, is there a migration path? I mean, can we know that technology is going to change? Can we move from older to newer versions and not have to take the entire system down in order to make that happen? Also, security, privacy, and safety goals. Those policies -- I mean, there's been so much work and attention. A very important area for being able to make this business value propositions work is that we need to make sure that we have these items settled and in place. And so we have certain policies and things like that. Do they exist? Do they cover things like confidentiality and accountability within them?

Next slide:
OK, so that gives a high-level view of what we did in the landscape document and where we saw the status of that. I'm going to now just have a couple of slides on what we're doing with our strategy for addressing interoperability: our line of attack, and the steps that we're taking to align the buildings automation community on interoperability.

Next slide:
So I'll talk about three main points with the strategy. There's a broad space. Everyone out there knows there are many different types and sizes of buildings. Different uses for those facilities, and all. Our initial target is to look at small / medium commercial building scenarios. So we're doing this because it requires low-cost installation. We can't -- these buildings' equipment, if it's going to be automated, needs to go in quickly, simply. It can't cost a whole lot of money for integration to happen. They tend to be simpler buildings. So we have maybe an easier time or easier lift in order to get them those components and systems to work together. It has -- you could argue that it has the most to gain from these interoperability advances in that it's in that spot where there is a commercial reason for investing in these technologies and having them work together. And that's maybe true of the residential case, as well, but maybe a little bit more difficult to put forward in a real business sense on the residential level, because everybody is making their own personal decisions basically at that level. Then, it's an example, if we do this with a small and medium building sector, then we can look at that for expanding into residential and larger commercial type establishments, and things like that, to do those more-complex or where the cost differences are even greater. So we're trying to offer also something a little bit different from the regular standards process. So we want to engage stakeholders to develop a vision. That's not so unique in the standards process. There are groups such as EESCC and ANSI that are moving forward with some version work there. And we want to leverage and build on that. But I think the other thing we want to do that's really maybe a little bit different is to develop an open, examinable, reference implementation. Something where, we can build it before the standards are made and demonstrate some things, or have people build these things so that it can inform the standards making and it can bring people along with maybe interoperability issues that are a bit esoteric and difficult to understand. So when we get -- as we look at these things and look at the vision aspects, we want that to inform then and create an interoperability roadmap, which would consider those reference-inspired interfaces and look at the approaches, you know, how we can incorporate where we are now with existing technologies where we can. What other priority that we should be focusing on. And always acknowledge that new methods and tools and technology will need to emerge. We won't have all the answers in terms of how to get there initially.

Next slide:
So the plan of attack looks like this. We have a landscape that I've just kind of gone over. We're in the process of developing this vision, and we had the first meeting that I'm going to report on in a moment. And in parallel with that, doing some reference implementations that go along with a multiyear roadmap, making it and refreshing that.

Next slide:
So now let's get to the connected buildings interoperability vision technical meeting, and I'll give you a summary of that.

Next slide:
We'll go over the attendees, some concepts that we provided, as a context for visioning work. We had some great presentations from industry, and I'll just highlight a couple of things. Just don't have the time to go into that. But the slides -- I've hidden some slides. You have those who want to look at the slides afterward, can see more details. And then we'll look at vision discussion topics, what the future will look like. We had a couple of stories, and I'll go into one story and some of the comments that we received back on that, to help with this, you know, what should go in the vision document. And so our desired outcome was an outline of the scope and content of buildings interoperability vision, and I will highlight some points from that, that came out of the meeting, as well. And then just some general observations before concluding the meeting.

Next slide:
So here's the attendees list. We had roughly 58 attendees from many different sectors attend. It was great to see the breadth of representation.

Next slide:
We did some outreach to try to get most of these stakeholder categories represented. The pie chart down below gives an idea of the -- like appliance manager, manufacturers, building automation systems, the energy service companies, government R&D organizations, tend to be some of the largest. But we had good representation from a number of segments.

Next slide:
We also heard from some really, I think, leaders -- I'm not saying all the leaders in this area at all. But we had Samsung, Bosch, SmartCloud, the Allseen Alliance, Honeywell, Siemens, Iconics, SkyFoundry, ETS. All provided some presentations, really, to help with this visioning, get us in the mood for the visioning discussion that we were going to have. Several of these companies are doing work in the IOT space, and like I said, I just don't have time to go over all of them.

Next slide:
So I've taken a few just to give you a flavor of the types of information that was provided from them. Samsung is doing a lot of work in the IOT space. They see -- there's a number of proprietary ecosystems out there. They belong to several of them. You can see in this diagram roughly three of them that they're very much involved with. There are changing platforms out there. There's devices that need to be accommodated. They're being added later. Many groups are involved. De facto standards are being formed. It's fragmented, disconnected, and the speaker basically was pointing toward that maybe more open-source ecosystems could be the better route. There are certain open-source standards that are out there that are getting some uptake, and maybe a place for coalescing direction and alignment with players.

Next slide:
In the case of Bosch, they had some very good points on the number of application protocols that are currently out there. They -- you know, for IOT to succeed, they are committed to open-source standards. They see that as what's really going to be -- you know, the direction in which we'll align different companies together. They also gave a quick report on some work that they did with machine-to-machine standards in a demonstration there.

Next slide:
The Allseen Alliance is actually an alliance of companies. Samsung was one of those companies. This presentation was from Microsoft, as a member. He discussed the AllJoyn Framework. This is trying to standardize on a single protocol. It looks at a network technology and cloud-based sorts of services. And in this particular case, there's a gateway agent that every smart device would have, that would allow it to then communicate into this network. So this type of platform or framework is -- this is just an example of one of several that are out there that are emerging and we'll need to see how those flesh out.

Next slide:
Iconics provided a very, I think, practical presentation. They're an integrator of building automation systems, so they -- you know, standards is very important to them. And interoperability -- even as an integrator, they would like things to go to better -- come together more easily and simply and reliably. So these application protocols at that point value type of level could be moved up to where there are more richer information models. Have some standardization on the objects and classes of those things, property naming and business logic behind it. They provided some examples where they've had some success with OPC Unified Architecture and their PubSub communication model. And they, of course, because of their role in integrating all sorts of devices and systems, they are constantly evaluating protocols.

Next slide:
SkyFoundry is a group of interested parties looking to really attack some integration issues with buildings. They have a Project Haystack, which is pointing out this lack of standardized naming conventions. And so it becomes very difficult or labor-intensive to map data between different servers or different versions of building automation systems. So we get things that can't be resolved just by naming. So they've come up with an approach for trying to get these standard tags that you could put on equipment and have -- thereby be able to reduce this engineering level, kind of move further into that information layer, of interoperability, with a common understanding of semantics.

Next slide:
OK, so with that quick summary, let me go into -- the meeting went into a set of vision discussions. And in order to kind of break the ice there, we came up with some vision stories.

Next slide:
These were meant to be inspirations for what buildings interoperability would look like, say, 10 -- 5, 10, 15 years out in the future. So we wanted these to be in line with the types of things that are basically happening already. We can see these as extensions, maybe, of what's going on with smart phones and tablets and things like that. Home electronics connectivity that is emerging. There are many emerging industry standards. Many of these play into that open software type and open-source type of community. But there's open data initiatives in several different areas. Community vocabularies, and ontologies. This is that information-modeling layer. Secure and open messaging. A couple of examples of those that are out in the wild now. And business process modeling. A few standards there. Again, more work could be done there. Internet of things is happening at many different places. Certainly IETF and IEEE are a couple of them. 1547 is a standard for distributed energy resource integration in the IEEE. And then, business-to-business interoperability. So there is some building information exchange. COBie is an example of that.

Next slide:
We provided this view as a way of imagining what that future would be. So I think one of the things that came out of that: We talked about a platform with which things get integrated. So somehow the building operator needs to be able to look into his building and find his smart equipment and be able to link it together and accomplish the processes that that person needs to accomplish. It also needs to communicate with outside parties, particularly in the future. So those are basically those actors that were in the framework that I talked about earlier. Now, each one of those -- the equipment down at the bottom, smart equipment down at the bottom -- it has its own platforms, and it's running on the other parties that the building would be interacting with. It's going to have its own platform. And so the system integrator's job, which could be in some cases the building owner, if he is knowledgeable enough, is really -- you know, we want to make their job of mapping between platforms a lot easier. So we looked at these platforms for hosting services and apps much like you would download an app onto a smart phone and be able to support that type of level of integration. And these various actors that are involved.

Next slide:
So looking at the building integration stories, we had one on internal interactions in the building -- the building operator talking with the equipment in the building. We also had -- I'm going to go into that in a little bit more detail here -- building service provider story. We had integration with market service providers, integration with distribution service operations. And those were each breakouts by different portions of those who attended the conference.

Next slide:
And so again, you can see slides and more information on this in the proceedings document of the meeting, to go into more detail. But just giving you an example, a highlight here: For the buildings internal interaction story, this was involved. The automated systems within the buildings, you want to do something like buildings energy efficiency with those systems, as well as have your occupants and business processes -- occupants comfortable and business processes taken care of. The description here is really looking at the small building through the eyes of its operator, focusing on the technology integration and drawing from this type of smart interaction like we are seeing with smart phones. So the actors in the upper right here: The value proposition is trying to coordinate these things at lower cost, and enhance the energy optimization and efficiency of the building.

Next slide:
Some of the comments that we got in the breakout were that we need to -- you know, this type of story needs to consider the integrator with appropriate configuration expertise versus the small building owner. So, some people, you know -- in the future, can we make it easy enough that a small building owner is there, or we're going to have certain requirements, hopefully simpler requirements, with which you would -- an integrator would need to step in to make this happen. It needs to be more decentralized. So the concept of this kind of platform for integration from the building operator point of view needs to -- this was a good point, I think, that we really need to also be thinking of the devices as each having their platforms, as well. And maybe some of those platforms are set up to interact with each other pretty much off the shelf. Customer choice is very important in all these stories. You want to be able to point out that there's different products to choose from, different levels of functionality, that can be purchased at different price points. There are certain complications involved that need to be covered, like owner versus lessee, and people like regulators that need to be included in that as actors, in such a story. And attributes. One thing the interoperability maturity model and the attributes for interoperability seem to provide: a pretty good list for consideration. So that's something that I think we will continue to look for, these interoperability requirements using tools like that. And then the last point here is ecosystems need a regulatory requirement, an industry leader for change. So some sort of an example of that was coming up with something like a virtuous cycle, where there's a mandate, for example, of reporting desired metrics and incentives for reaching those levels.

Next slide:
What all these different breakouts contributed to: a vision outline. These are -- I have two slides here to go over the points, and I just don't have the time to go into these in detail. But you know, we really need to within this document articulate the vision statement with the objectives and what we desire as outcomes. The audience, it's clear -- we need to put forward the value -- the audience that this vision would be for, and the value propositions and potential opportunities for that audience. We want to emphasize distributed control and coordination over a centralized type of thing. That's so that we can build smart products that are out there, you deploy them, they connect. So we have got more of this coordination that's occurring rather than a system that's got this very centralized type of approach. There was pretty much uniform agreement about that. Anticipated the arguments of naysayers. So that's to, I think, acknowledge different positions that may be out there and see that we have a response to those positions. We want to use the stories; that was felt to be a good thing. But from those stories, describe the needs and the differences with more detailed use cases. Describe buildings classifications. So even though we've kind of focused on small / medium, there's still a number of classifications that we need to go through with desired interoperability targets within there. And of course, identify these interoperability metrics.

Next slide:
It's a heterogenous technology mix that we want to be able to support. We need to include the fact that there are legacy investments that have to be accommodated. Shared information models for buildings was brought up as again a very important area. Education on interoperability in general is needed and should be a part of this vision. Commitment to the safety, cybersecurity, and privacy issues needs to be covered. The things that are happening and emerging out of the IOT space and in IT in general, we really need to be on that kind of cutting-edge with where IT is going, because that's what the buildings community is going to need to draw on. Not just buildings community; all the industrial communities all will be drawing on that same set of things, as well. So we need to list who needs to be involved. And marketing and promotion aspects, at least consider how we would do that, moving forward. So things like establishing maybe like a smart building index could be very helpful.

Next slide:
OK, I'm getting close to the end here, so we'll have some time for Q&A. But, we have a couple of things I wanted to say, some observations from the meeting. This is kind of a synthesis or a distillation of takeaways that we had at PNNL. I think we certainly heard that there's a significant opportunity to advance interoperability in connected buildings. The fact that, you know, the height of the technology right now seems to be putting tags on points and getting some standard naming together. It's an illustrative where we can go more fully into that information level and into the business process levels. The audience of the work needs better definition. And so why should these stakeholders be interested in advancing interoperability? You know, what is the government role? We need to better articulate that. The technical experts can be difficult to engage, versus the business developer. So there's a certain level that want to get engaged, based on emerging business for their organizations. But we also need the technical experts there, who really can say, yea, this is the way standards should move, these are the fundamentals that we really need to highlight and see are covered in the vision. And IOT players, they have lots of different forums with which to play with. Getting their attention into the connected building space can be difficult or a bit of a challenge. So I think we need to try to do a better job of that. The last part here was, there was, I think, a real need, partly on this buildings stakeholders and in what's their interest in advancing interoperability. If we had a compelling application, something that could be a catalyst for getting the attention, I think that would certainly help in trying to develop this community and alignment behind standards and approaches and testing, etcetera, that would help advance interoperability.

Next slide:
OK, so our next steps: We're going to revise the interoperability landscape draft document, so please download it, please review it. If you get comments in by May 31, we will see to addressing those comments in the next version of the document. But even if it has to be after May 31, please, be interested in your comments on that. We're going to continue education and outreach such as this webinar here, to better communicate the value and potential to our advancing interoperability. So white papers and things like that get our message home better. Draft that buildings interoperability vision document. We have a good starting place now, after the March meeting. And that will then feed into our roadmap development. We're also going to be looking at the prototype reference implementations, identifying, you know, what would be the interoperability characteristics that we think would be most valuable to demonstrate and refining the requirements for such a reference implementation, so that we could consider various projects, challenges, or competitions for doing that work.

Next slide:
A couple of parting notes here. These are the links to the proceedings for the meeting, a link to the buildings interoperability landscape draft document. If you're interested in contributing to this vision and roadmap, I encourage here and solicit your attention to this matter. And please contact me at my email address or give me a call at my office.

Next slide:
So with that, we have a few minutes left. And I will turn it over -- let's see, I have Andrew Nicholls on the phone here, who can maybe help me with some questions, if there are any out there.

Andrew Nicholls:
Yea, so Steve, this is Andrew. And we had one question early on, which is fortunately easy to answer. And that is, when will this presentation and -- including the audio portion of it -- be posted? We have to go through a little bit of ADA -- American Disabilities Act -- processing on the files, but that should be available by the middle of next week. And we will send that link to participants on this call. So that's one question. We have another question here, which is, is this effort going to cover interoperability with water and gas grids? Building owners are connected to more than one grid.

Steve Widergren:
Yea. That's a great question. A very good question. So right now, the kind of the lead-in example that we've -- story that we've used is more linking with the electric system. And for the grid-type services, as one example, but this is a buildings connectivity issue in general. So you know, it's really to be about buildings. So water systems, gas systems, and actually the types of efficiencies that could done, maybe switching from electric to gas, in terms of heating or what have you, depending on the costs of each of those types of things, those would all be valid scenarios with which we want those systems to be able to connect and to address applications or use cases such as that. So, yea, the answer to the question is, it does cover all those things. I think, we're starting out with, based on some of the heritage of this project, more electricity-oriented, but those should all feed similar use cases for other types of infrastructure and services.

Andrew Nicholls:
Another question here is, have you considered the value of a universal network access port? Are you aware of the CEA 245 work standard for such a port that is being piloted on several different appliances by EPRI? End of question.

Steve Widergren:
Right. So I'm not aware personally in detail. I'm aware of the work and the project that is going on there. I think that, you know, there are many initiatives going forward, trying to pick the one that will actually make it. In the case of EPRI, they would tend to be on an electric power side of networking type of thing, versus other infrastructures. But I really can't comment in terms of the details or what have you. I'm sure the work is something that needs to be covered and should be in the landscaping, if it's not already in our list of standards and efforts that are going on.

Andrew Nicholls:
Another question here is, Steve, this goes back to slide 48. Given that the first story is from the point of view of the small building owner, why were none of these folks among the 50 at the meeting? And that's the end of that question.

Steve Widergren:
OK. OK. So the ...

Andrew Nicholls:
Slide 48.

Steve Widergren:
OK. ... Well, OK. So that particular slide was on the building internal interaction story. And we did actually have some players there that do small buildings work. They provided energy services and integration services to buildings. They tended to be smaller companies. For an example of one that comes to mind, is Ingenuity. They do things like fast-food restaurants and other small-box, strip-mall type integration. So of the ones that I gave in the examples, and who did the speaking, they tended to be larger companies, although ETS is a fairly small company. They still do some fairly large buildings, in terms of the diagnostics they work on. So we did have some representation of small buildings there, businesses there. They tend to have -- in those smaller companies, they have less resources, so I think it's a little bit more difficult for them to attend these. But the outreach into that community is something that you know, we definitely will continue to work on.

Andrew Nicholls:
And one final question: In your final slide, you did show some URLs, Steve, that reported on the Seattle meeting and some of the interoperability work. Thank-you for pulling that up. If you Google "buildings to grid," you should come up with the DOE Buildings to Grid website within the Building Technologies Office. And there's a lot of content on that website, which includes other technical meetings, the interoperability meeting, all the presentations that were given at a number of different meetings, including the March meeting. So there's a lot of riches there. So you don't -- if you can't copy all this down, "buildings to grid" on Google should take you to the DOE website. And then you look under "Meetings," technical meetings, and there's a number of meetings are posted, including the interoperability meeting.

Steve Widergren:
Right. That's a great point, Andrew. And some of these links will also kind of -- you could backtrack to other pages of related sites. This is just one project. I think Kevin Lynn tried to provide some context of, DOE is doing a lot of things just within the Building Technologies Office. There are a number of activities. We're just one project with a number of related activities that are occurring. And so, by following those links -- looking, bring that up in Google, you can see a host of related things that Andrew submitted.

Andrew Nicholls:
One -- I know we're at 3 o'clock, but I see a couple of other questions have come in. I'll just throw one more at you, Steve. In terms of stakeholder involvement, how are electric utilities responding and engaging in the processes at hand? End of question.

Steve Widergren:
OK. So electric utilities are definitely engaging at the grid integration level in groups like the Smart Grid Interoperability Panel. And they do participate within a group of buildings to grid and industrial to grid, but probably less so than some of the things that they're looking at within their own infrastructure. At our particular meeting, we did have utility representation, and a number of interested utilities who could not make it. But it's an area, I think, for this work where we do need better representation. They are, of course, interested in the use cases and the stories that would have, you know, distribution system operations and electricity market type aspects associated with it. So you know, being able to have -- sort of focus in to the various areas is going to be a challenge, I think, for the project. But we will be continuing to reach out to the utility stakeholders, as well as to the other players that were in the framework document that I presented.

Andrew Nicholls:
One final question: How does this work interface with transactive energy? And -- so that one should be fun, Steve.

Steve Widergren:
OK. Alright, so, well, Andrew, you helped a bit in that. If you go to the Energy.gov websites or you Google the "buildings to grid" work there, you'll see a section of that has transaction-based -- actually, it's even referenced in the slide decks here -- some work that was done where integration is expected on some of these items to be transactive in nature. Or that some of the work in the transactive energy effort, for those of you that are familiar with it, would be applied, that fit naturally here. This work is looking at the interoperability aspects, so it's transactive and the interoperability of the transactive, would be more of the focus here. But it's not just transactive energy. There may be other approaches and reasons for integration that would not necessarily have exactly that same style that's being reported there. So I think there is a linkage and a relatively good linkage there. But we are focused more on interoperability and not just transactive energy. With that, I think we're already a few minutes over from our target here, so I want to let people head off for the rest of their days. I really appreciate your questions. Your attendance of the meeting. And again, if you're interested, please contact me, and I look forward to future interactions. With that, I'll sign off and wish everyone a great day.