Solar Consultants are a Big Barrier to Smart Energy

Smart energy names the techniques and technologies needed to manage energy flows and energy supply and demand when energy generation and energy storage are as distributed as energy consumption is today. During the early years of distributed energy, distributed energy resources were so small as to be losable in the noise of the grid. Installations were treated by utilities as if they were just another utility installation. This design approach has become the single largest barrier to distributed energy. So when are we going to get smart about distributed energy?

Grid assets are managed by central control. This only works so long as the assets are central and the assets are centrally owned. Distributed assets should have distributed ownership. Their purpose is often local, and the local owner has their own reasons for deploying them. As I have written before, today’s integration techniques actually discourage distributed storage. Distributed storage may be the single most critical requirement for smart energy to succeed. 

The first generation of PV consultants are so focused on the utility that they do not even know why the consumer is installing the system. Their reports to potential customers emphasize gaining payments from the utilities over obtaining on-site benefits. The reported risks to the customer are regulatory, i.e., will the local commission hold firm in forcing the utility to pay these rates. Even financial matters look to the utility: will utility throttling of generation interfere with PV as an annuity.

When asked about local benefits, of self-sufficiency and of resilience and of local control, few of the first-generation consultants have any answers. They look discomfited for a minute, they go back to reciting interconnect rules. From their actions, one would induce that they see no value to the site at all, merely an opportunity to loot the public weal.

This looking to the utility reduces the value proposition to the customer. The central control model reduces innovation in systems. As many realized after Sandy, forward assets of a central authority are of no use after a crisis. Without central control, they simply turn off.

The answer is to turn this model on its head. Smart energy manages from the edges, not from the center. Smart energy treats homes and commercial buildings as microgrids responsible for their own power. Each of these microgrids is a node within its neighborhood, able and willing to share its excess power as needed. A microgrid that contains generation or storage may even decide to serve those neighborhood needs before those of its constituent nodes. Those decisions, though, must be negotiated using sound market approaches.

If Solar consultants would start acting as if they believe solar energy is a good idea for the customer, and not just a way to extract regulatory rents then solar installations would increase. Until they do so, every installation will take longer, and cost more, than it should. Customers currently in the process find the solar consultants, and their regulatory-centric models, to be the biggest barrier to installations.

Smart TVs, OBIX, and your next Commercial Building

As regular readers know, I have been caught up in the production of OBIX 1.1 for most of last year. OBIX has world-wide use in niche locations. It has open source platforms. They do not interoperate as well as they might. To improve interoperation, and ti improve telemetry, we started work on 1.1. Then the Smart TV Alliance upped our game.

But first, a little about how 1.1 is shaping up. We broke oBIX up into smaller pieces, to make it simpler for a programmer to tell what rules they are using. With smaller pieces we can more easily say “An Application conforms only if…” This makes interoperation of different platforms much more likely.

By last May, we had isolated the core information model and interactions (OBIX 1.1) and separated out Encodings and Bindings. We added features to support large data-set telemetry. We added the capability of adding metatags to points, to support semantic sets such as Haystack and BIM. We specified Common Encodings for OBIX (XML, JSON, COAP). XML is the original encoding. JSON is much beloved by current web developers. COAP, or the Constrained Application Protocol, is on track to be the recommended communications platform for the Internet of Things. COAP is designed to translate HTTP down to the level of constrained and lossy communications. We also developed two binding specifications: REST and SOAP. The REST binding formalizes what Tridium has long provided. The SOAP binding is typified in the multi-tiered architecture used by ETSI projects and by products such as Energle.

These formal encodings and bindings make it easy to tell what the other side expects. A typical web page might integrate with a server that uses the OBIX 1.1 model encoded in XML and bound with REST.

Then I received email from the Smart TV Alliance. They liked what we were up to, but wanted us to add a Binding for WebSocket (RFC 6445). That was easy enough to do—which is why we went to the multi-part format described above. WebSocket provides for full-duplex (two-way) communications over an HTTP connection. WebSocket is a standard part of HTML5, so you are probably reading this in a device that supports WebSocket already. The Alliance proposes to use OBIX encoded in JSON and bound to WebSocket.

The initial goal of the Alliance is to create a common platform for TV apps. Today a company such as NetFlix must write an app for each TV. Under the Alliance plans, the same app would run on televisions from LG, Panasonic, Phillips, Toshiba, and Vestel. These televisions will all support HTML5 applications. I expect an explosion of TV-based apps as companies exploit the Alliance eclipse plug-in to write once, run everywhere.

The Smart TV Alliance announced their SDK at the Consumer Electronics Show, just as the latest OBIX specifications went out for public review.

Digital Signage, whose platform is essentially flat panel televisions, will be the first commercial building system to be remade. It takes only a moment to imagine how advanced signage will change with a consistent local HTML5 platform. Multi-screen digital advertising company YuMe is already a member of the Alliance. Custom development kits will need to remake themselves. Wayfinding, building directories, restaurant menus with dietary information are just a few of the applications that will change rapidly.

But that is before we consider WebSocket and OBIX. The Alliance assumes that WiFi is available. The first add-on application that comes to my mind is the smart home theater. This requires communications with lighting and with sound systems and other consumer electronics. (In possibly related news, Apple, not a member of the Alliance, pushed through an RFC draft for aggregated service discovery to support their televisions.) Mobile internet provider Obigo brings the Alliance into smart phones and PDAs. I wonder what applications will be built based on dynamic interactions between phone and television. Is this the end of hunting for the remote?

From there is it a small hop to communicating with the WiFi enabled thermostat. This is sure to intensify sparring between Honeywell’s WiFi SMart and Google’s Nest. U-SNAP can bring WebSocket to standard appliances. Smart homes might at last be here, not just for hobbyists, but for the rest of us, using existing infrastructure.

This brings App culture and App technology to smart homes, and, to me, that means Smart Energy Apps won’t be far behind. Homeowners won’t tolerate long integration requirements, so energy system discoverability is part of this picture.

It is only a matter of time before this creeps back into commercial building energy management. The predominant building system middleware is already built on OBIX. Digital signage everywhere can provide energy management platforms everywhere. Buildings will adopt new apps if the old ones do not perform as they like. Will there be Freemium Energy Apps?

Only time will tell, but it should be a wild ride for the next few years.

Smart Energy with a little bit of Seoul.

My visit to Seoul this month was fascinating. The country of Korea built its infrastructure essentially from scratch in the last 50 years, and in doing so was able to use modern technology to challenge some fundamental assumptions that we make in the USA. IP-based telephony predominates based on pervasive free Wi-Fi. Custom tailors use radical outsourcing mediated by IT to provide near-instant services. The National Virtual Power Plant (NVPP) is as up-to-date as any, while using big-data tools in ways not often seen here. There is a desire to embrace the new without fear that seems young and fresh in the way the US often does not. But somehow, the single observation that stays with me is how the use of IT to challenges our assumptions about natural monopolies.

The Seoul Metropolitan Subway system is by far the best I have been on. The signage is unusually good. Many stations have large interactive maps. Every car has digital signs that display the next station in multiple languages. Music plays on the platforms to warn of each impending arrival. In the winter, automatic seat warmers make even the ride itself pleasanter than expected.

The fare system is seamless. The system pioneered in Seoul is now used in many US systems: a card, a wave in, and a wave out, and a charge based on beginning and ending stations. The systems to add money to your fare card will tell you the remaining balance instantly, without inserting the card, or needing to punch buttons. Unlike in the US, every station has prominent stations on which to drop your card and get cash back. The $0.50 deposit on the card itself is just as easy to get back. There is even competition for these cards as three subway cards, one credit card, and several debit cards can be used interchangeably with your transit card. In short, it is customer focused, consumer friendly, and feels like anything but the bureaucratic experience it is in the US.

The high-tech experience extends into the amenities as well. Subways in the US are often dead zones. In Seoul, each line provides choices of digital connectivity: 4G, WiFi, DMB, and WiBro. This supports the widespread use of IP-telephony in Seoul; without the legacy commitment to lines, almost every smart phone uses the almost universal WiFi. (More on that later.)

All of this is supported by an easy to use App, one that puts the well-regarded BART App to shame. The free App, available for all the usual platforms, works out routes and provides station by station information with precise departure and arrival times. The cost for each route and stop is computed and displayed in advance. A potential rider always knows whether to rush, and when he will arrive.

In the US, this would all be delivered through a semi-private agency, a Transit Authority. In the Seoul, the nineteen subway lines are built and operated by ten separate companies. Some routes may have a higher cost per kilometer, or per station, but that information is readily available before your ride. Fares are automatically allocated to the different companies based on the same services that compute the entire fare. With appropriate use of IT, the multi-vendor service is provided as if through a single provider.

Regular readers may recognize that this is the model of Transactive Energy.

The Seoul Metropolitan Subway system tears down assumptions about how natural are our regulated natural monopolies. To someone who considers the smart grid, it stirs re-thinking of how we consider last mile distribution in a distributed energy world. Just as South Korean phones use the connectionless protocols of the internet to avoid considerable high-cost build out of telecommunications infrastructure, transactive energy and distributed energy can provide better service at lower costs.

To gain these advantages, we must embrace the distributed multi-supplier business models that enable them. Trust capitalism. Embrace minimal market design to limit friction when changing suppliers several times a day if desired. Use IT to smooth any bumps in transition. I’ve written about this in papers on microgrids and autonomous power nodes. It was nice to see it in the field.

Finding a Needle in the Internet of Things (part 2)—Buildings and Building Systems

In a previous post, I described how vCards are used throughout standards-based scheduling and calendaring systems. Many different vCard standards coexist in today’s organizations. I also described how directory services, especially LDAP (the Lightweight Directory Access Protocol), are the well-established means to enable wide secure access to the information in vCards. In this post I discuss current efforts that will expand these existing standards to support buildings and their systems.

The most frequently scheduled building-based resources are public rooms and building systems. Public rooms are invited to meetings as are other attendees. Smart buildings can optimize energy use while preserving amenity if they know when and by whom the building will be used.

An enterprise scheduling may include hundreds of schedulable conference rooms. These resources are generic to some extent, but the potential scheduler would like to filter the list. Show me the conference rooms that are near me, and that will seat at least 8 people, have an internet connection, and have a projection screen. If there is a cost, show me what each costs per hour.

Two things stand in the way of adding this as a standard function. Today, there is no standard for what the names of each of these features is. In other words, there is no Resource vCard standards for rooms. The second is that there is no source for this information. Few want to take on an additional data maintenance task to enter this information or to keep it up to date. Fortunately, there is a solution to both of these problems, and that solution is BIM. More particularly, the solution lies in COBie Lite.

COBie Lite describes a strongly typed and validateable data model. COBie Lite has been stripped of all process, it does not matter what the source of the information is. The information in COBie Lite can be exported from the BIM used to design and build a building. COBie Lite provides a formal definition of the information that should be collected during commissioning. COBie can be imported into all of the major Computerized Maintenance Management Systems (CMMS). Today these systems are roach motels holes of COBie—data checks in, it doesn’t check out. That can and will change.

There are many sources of COBie lite. In each of them, the information is created or maintained to support an existing business process. A standard transform of COBie Lite can produce all the information needed for a standard Resource vCard for rooms. I call this standard the BIMcard.

Building-based systems also face problems of dynamic integration. Traditional building management systems are highly proprietary. Even when fronted by standards-based middleware, say a Tridium JACE exposing oBIX, it is still hard to integrate with business functions in any scaleable way. Let me be clear what I mean by scaleable. A BAS might take one engineer one week to link up BAS and some fixed enterprise functions. To link up 5 buildings might take a single engineers 5 weeks, or a 5 engineers one week. If it was a scalable process, we might expect the 5 engineers could integrate 100 buildings in two weeks. If the buildings can integrate themselves, that number goes way up.

A common BIM-based model provides a path forward. A commissioning report can produce an equipment-only COBie-based BIM. If there is a building model from construction, no matter how incomplete, it can provide a framework to host that COBie-based BIM. A profile for Building System Resource vCards can be defined based again upon COBie Lite. BIMcards, then become the searchable entrée to the systems in buildings. It is not hard to imagine BIMcards for temporary equipment, wherein they can register themselves in the building.