DER systems in the house and small business

This post is part of the continuing Paths to Transactive Energy series. You can find them all listed by clicking on the matching metatag at the bottom of each post.

The purpose of an energy management system (EMS) or building management system (BMS) in a home or commercial is to serve the owner or occupants of the home or building. Only secondarily is its purpose to “serve the grid”—and then only to the extent that it is rewarded for doing so in a way that supports its owners or occupants.

Every system in a house or building is a legacy system from the moment it is installed (manufactured, actually). No matter what standard we may posit for future use in home systems and home integration, most systems managed by the EMS or BMS will be legacy for some time to come.

The makers of EMS and BMS will compete based on user (and system) interfaces as much as on performance. What is the easier-to-use interface? Which system gives me reporting that I like better? Which system can I connect to my corporate scheduling system? The inputs through these interfaces will inform the EMS/BMS as it responds to market signals from outside.

A common information model will make this market (interfaces) more competitive. The first draft of that information model was delivered last year by ASHRAE 201. Today’s EMS and BMS will work through local direct control and increasingly through a descriptive framework supplied by ASHRAE 201.

Early adoption of transactive services in the home and office will most likely to be for integrating DER inside the facility. The resource frameworks defined in the transactive energy specifications enable a device or system to express capabilities over time and to make forward commitments. The direct control system in the EMS/BMS can negotiate for future requirements without getting into the weeds of understanding a battery management system.

Battery management systems are increasingly supporting complex internal ecosystems of their own, embedded with integrated circuits and composed of hybrid technologies. These circuits manage battery life through creative monitoring of charge rates, temperature, and power factor. The BMS may take a cell off-line, recondition it over much of a day, and then restore the rejuvenated cell to full service. Flow batteries manage different chemistry and physics to manage dendrite development. Hybrid systems combine systems optimized for long slow charging and discharging with more nimble technologies able to take and provide fast charges.

No businesses will benefit more from virtuous markets for the rapid development and evolution of storage systems than those of the EMS/BMS developer. Rapid evolution and thriving markets could mean the unending development new drivers for new batteries. Even with drivers in place, batteries change in capabilities over time, and based on usage patterns; a full understanding of this year’s capabilities may not be adequate for optimum interaction with the same system after a year’s use. The solution is for battery management systems that are self-managing, can express their capabilities over time.

This requirement describes a transactive node able to describe its forward capabilities and make forward commitments. A battery system must be able to commit to service directives such as “be ready to provide a specific power curve for the 12 hours beginning at dusk”. A battery system must be able to communicate that if it commits to a transaction, it will needs six hours of charging to recover. It must be able to commit to standing requirements (“always have four hours available”) while fully discharging individual cells to maintain capability.

Renewable generation can pair with such systems, and will sometimes interact with a storage system to provide a single hybrid service. (This may well be structured as a transactive nanogrid interacting as a single node within the microgrid). Renewable generation, like battery management systems, is most likely to be part of a new installation. Such systems will likely follow the transactive model for behind-the-meter integration as soon as intelligent power controllers support integration by semi-skilled labor.

This describes a hybrid model, with the bulk of legacy and consumer equipment under direct control of the EMS/BMS, but informed by the transactive commitments of the newer systems. In this hybrid microgrid, the market is shallow, so the resource descriptions are useful.

Work Plan for oBIX 2.0

Some of you know that the oBIX Committee (open Building Information Exchange) is meeting again. The work is moving ahead on multiple fronts. We have separated encodings (XML and COAP) from the core specification. We are working on separate transport specifications for SOAP and REST (including JSON). We are doing a refresh of the core specification for consistency and conformance. I am most excited, however about the oBIX 2.0, the enterprise services.

The core specification (1.x) requires each oBIX server to provide a lobby. Clients can ask the server what is in the lobby, and thereby discover how to interact with the system behind that server. Contracts are special purpose agreements that are added to the lobby. Clients can invoke contracts by accessing the elements listed in the lobby. Vendors and integrators can add functionality to an oBIX server by creating contracts to add to the lobby.

Our current plan is to define enterprise services by specifying new types of contracts to place in the lobby. oBIX servers will then state which types of contracts they support, which encodings, and which transports. As of March 2013, we anticipate the following sections:

Energy

oBIX Servers are likely to participate in collaborative energy ecosystems including those managed by Energy Interoperation (OpenADR 2.0) or as described by ASHRAE SPC 201. We plan to incorporate information models and semantics developed to support the US national Smart Grid efforts, including Green Button. Potential contracts include not only energy usage reporting, but projections and commitments as well. We anticipate leveraging the existing OASIS Energy Market Information Exchange (EMIX) Specific information exchange requirements as defined in NAESB REQ 21

Advanced Reporting and Aggregation (Historian)

The historian does not scale well in its current form. A request for, say, a one year history on several sensors is larger and more unwieldy than it need be. It may be necessary to support variations such as projections. We do not want to break compatibility.

Alarm Logic.

This topic extends alarm contracts to include logic for alarms. If A happens followed within three minutes by B. If the cycle between occurrences of A is less than 5 minutes. This is in effect defining diagnostics with interactions between functions. If I am talking to 100 oBIX servers, I may want to apply that diagnostic to every AHU attached to each of them.

Building Information Models (BIM)

In buildings, control systems operate building systems. Building systems support the various spaces in a building, whether securing them, monitoring, them, or conditioning them. The relation between a building system and spaces in a building is described in a Building Information Model (BIM). oBIX BIM contracts will describe how an oBIX server will make BIM accessible, and how to apply BIM as a semantic framework for the control points.

Enterprise Scheduling

Enterprise Scheduling applies the semantics of WS-Calendar to schedule interactions with building systems. This includes a notion of service oriented schedules instead of the control oriented schedules as today. (Example: Request room at temperature by 8:30 rather than Request room to begin heating at 8:10). This is likely to use the same semantic frameworks as security, i.e., to specify a room rather than a thermostat. Enterprise scheduling is made possible in part by the BIM framework as described above.

Security Composition

oBIX 1.0 defines a monolithic model, all or nothing, for access to points and settings. This access should be limitable by role and by organization. Advanced security contracts will define a means to define policy frameworks for secure access to oBIX servers. This is likely to be an intersection of roles, i.e., integrator, operator, tenant, guest as applied to business function. In buildings, business functions are defined by the spaces they are in. The relation between building systems and space can be found through reference to the BIM.

We will not define a mandatory set of roles, or a mandatory framework, but instead define a means to apply notions of space (say a particular tenant) and of role to access to an oBIX server. We anticipate a means to discover the roles available on a server, to map those roles into a discoverable space, i.e. BIM. This topic includes addressing federated security, and may include how to apply SAML, XACML, and similar specifications to oBIX servers.

Please contact me if you would like to join in this work.

Smart Energy in Industry: Introducing MRP4

Last week, I spoke at the Department of Energy’s Industry to Grid (I2G) Summit, a pre-meeting of the ARC World Industrial Forum. For me, it felt like something of a homecoming. Several careers ago, my biggest customers were manufacturers. In the late 70’s, popular imagination held US manufacturing to be dead, poorly managed and low quality. In a famous Newsweek article, a celebrity athlete boasted of a summer in the UAW, during which he deliberately added rattles to pass the time. As often happens, a renaissance had begun some years before public perception hit bottom.

As a young programmer, I was working with companies trying to improve quality while keeping costs under control. With double digit inflation the norm, the US was beginning its great inventory squeeze. A passing familiarity with the Japanese Kanban system could take you far in industrial consulting. JIT inventory was being supplemented by JIT production. In Toronto, at the world APICS conference, we split MRP (Materials Requirements Planning) into MRP1 and the new MRP2. MRP2 reached beyond the factory floor to incorporate sales budgeting and HR planning. A year later, I first saw AutoCAD, astonishing because it ran on a PC.

Those were the roots of today’s integrated global supply chain management. Eventually MRP2 came to cover all facets of a company, and was re-christened ERP. Time-phased resource acquisition is a critical component of today’s commerce. Executives in every sector now are evaluated based on ratios determined by how lean their inventory is.

Even when it makes no sense, we apply these management principles today. For example, Coal plants used to pride themselves on weeks or even months of supply on hand. Coal is easy to store, and it does not go bad. Still, many utilities today run on same day coal deliveries; any interruption of the supply chain, of the constant stream of trains from mountain to generator, would take a significant portion of US electrical supply off line.

This last week, we saw the effects of a similar lean supply chain in natural gas. The cold snap increased demand and reduced supply, causing affecting electricity supplies in Texas, New Mexico, Colorado, and California. Lean supply chains are brittle. Through ERP, we have made are electricity supplies brittle as well.

Current plans are that we introduce intermittent electricity sources, i.e., solar and wind and tides, throughout the grid. Today, we backstop these with the same natural gas whose supply chain we manage so tightly. Lean supply chains and thin markets demand predictability. When smart grids fail, lean supply chains can make then fail badly, and the effects will be regional.

Pulling this back to my early days in industry, APICS propagated the essential equations for to compute supply chain decisions. In those days before PowerPoint, I used to be able to write these equations, in the style of a grammar school teacher, on the board, behind my back, while facing my clients. Many of them depended upon another, the Cost of Stock-out (COS). The simplest COS was solely lost sales per day. The better ones started with opportunity costs and factory reconfiguration and extended to lost reputation and permanent loss of customers. It is easy to undervalue the COS.

Public Utility Commissions have made affordability their top concern for decades. Utility executives strive to make their financial ratios look like other industries. Volatile energy supplies will increase the likelihood of stock-outs, i.e., shortages of basic supplies. Lean supply chains and renewable energy create a dangerous mix.

The industrial decision-makers in the audience wanted a quick take-away on what smart energy means for them. Many of them generate their own power, and are looking for better ways to bring their excess to market. Others are just beginning to consider the effects volatile prices that swing every day. To me, it was easy, they are already the thought leaders in this area. Industry gave us MRP1 which grew into MRP2. MRP3 is ERP, the dynamic management of resource supply and use that runs our global supply chains and businesses of all kinds. For the end node, smart energy is MRP4, accounting for volatility of supply, and factoring it directly into scheduling on the factory floor.

BSI Part 3: The Metadata Problem

After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the third of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.

Metadata refers to information about data. While control systems for buildings can offer up an impressive amount of data, it takes far too much effort to figure out what it means. In a medium-sized commercial building, tens of thousands of points can take a month to unravel before useful integration with the businesses and lives of the people who occupy those buildings is possible. Throughout all the integrator must understand the technologies in use in that building. At the end, the integrator produces proprietary results himself.

Most of that integration effort is in deciphering what those information points mean. Is that point an internal point, useful only to the HVAC professional, or does it represent a room temperature, or oxygen level, of interest to the building occupants. Do these points describe one air handler or ten? Are all air handlers fed by the same compressor? What space, which means what business services, does each system support? The answers to these questions can be discerned by the trained professional, with the blueprints in one hand, and years of experience in the other. Today, they cannot be reliably determined by machine inspection.

We need a relatively few profiles to pull this off. Or maybe we just need some rules about profiles, and a place to create a repository. Too many profiles could just recreate the chaos we have now, in which metadata is all free-form tags.

There are several existing profiles for communicating with energy meters; we need to get to one. The profile model should be able to indicate what systems are behind it, by reference, to the discoverable catalogue of building systems and spaces. Whether you call it live load, or plug load, circuits and the space they support can be described in PLIie. Everything, of course, should be tied down to the space or spaces it supports.

BIM standards contain standard descriptions for how a space is used. The links to space, offer potential keys into business directories and business schedules.

The place to start collecting this metadata is during commissioning. COBie (Common Operations Building information exchange) defines a family of information models that can be handed over from a construction Building Information Model (BIM). These include a catalogue of building systems and the spaces they support. As retro-commissioning starts to follow commissioning standards, we would begin to get the benefits of the BSI-enabling metadata in existing buildings.