Profiling Economic Actors for Transactive Energy

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. These posts were written because the GridWise Architectural Council's Transactive Energy Conference begins tomorrow.

p>The communications defined in the common transactive services (CTS) can be used by every actor in transactive energy.

The needs of particular environments may require an actor to use different communications profiles. Security needs will be different for different environments. Security standards will change over time. Actors that participate only in small non-critical negotiations where both parties share a common owner may opt for lighter-weight standards to record transactions. These communications requirements will be expressed as profiles. These communications profiles will change over time without changing the fundamental information exchange between each actor.

There is profiling along a different dimension, profiling systems as economic actors, which can assist the system developer, the system integrator, and the system owner. These profiles describe the type of ends the actor has for participating in the market. They help system owner to understand how a new actor will affect the resource market.

Basic business interactions start with knowing who is a supplier, and who is a buyer. A similar distinction might distinguish the wholesaler from the retailer. A buyer approaches the farmer’s market and the supermarket chain differently, even when the goal is fresh produce either way. One is intermittently available in certain locations, one is available on a wide schedule and in many locations. It is useful to the seller to know which he is when designing his business. It is useful for the buyer to know whether transactions will be in cash or by card, and how to find the market location. Although the economic interaction is the same, these economic actor profiles help each market participants to meet his needs.

The purpose of the agents in the home (or in the office) is to enable meta-drivers to reduce complexity. I run windows. And when I plug in a device, and watch closely, I can see a human interface device arriving, being replaced by a pointing device, being replaced by the mouse I am using. My computer quickly drills down past the general to the specific, with specific devices offering specific functions. In the same way, a transactive energy capable device registers with the brain. In my model, it then describes what kind of abstract device it is. In this analogy, it goes as far as the “pointing device” but need not go all the way to device and control specificity. 

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.

Cryptocurrencies and Cybersecurity and Clouds

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.

Many of the hottest startups in the Internet Of Things (IOT) are cloud based. This is driven by: are cloud based. Motivations driving this include:

• Using powerful shared computing to reduce the cost of simple things in the house.
• Pushing inter-Thing compatibility into the clouds
• Providing a locus for high end user interfaces, on phone and tablet, over the web.

Of course a more powerful incentive is:

• Track everything that goes on to provide alternate revenues for the cloud provider.

The downsides of this model are that the cloud introduce new complexity and new failure points. There may be few costs for some sensors being off-line, but systems that do something must be smart enough to not do bad things without supervision. This principle was demonstrated decades ago in some factory robotics that impaled a worker after someone drove a forklift over the thick ethernet cable on the factory floor.

System owners should consider “Where is the cloud?” The Cloud originally meant “vagueness because it does not matter if the server is under my desk, in the local data center, or in a 3rd party hosting”

For a variety of commercial reasons, some large companies promptly markets a changed meaning for the cloud, i.e., the Cloud means only their hosting centers. This led to a push-back of the term Fog, meaning parts of the Cloud that are nearby, but could still fit on the original PowerPoint.

I think we need some fog to truly address the issues of distributed infrastructure, to provide reliability following insult to the distribution system. The insult may be attacks on the substations or it may be s due to an earthquake or storm. Telecom may be lost at the same time as power. If telecom is not lost at the same time as power, it may be lost days later as the POP as the local phone/cable NOC runs out of power.

Local control in the local fog introduces local integration costs. Each device may need to understand each other device—or the master device must understand them all. This leads to proprietary silos, systems that are not able to evolve. It also often dictates considerable end-user configuration as devices learn to talk to the master device. Where security is a concern (which should be everywhere), this must be difficult because of the intimacy of traditional integration.

Transactive integration assumes that each device or sensor provides a service. Transactive integration does not require that devices that are trading partners have any understanding of each other’s operations, i.e., how each one works.

Transactive integration introduces some new issues, especially in the security area. If my HVAC system can task my hot tub to accept waste heat, the HVAC system may need to prove who it is. The two systems may need to be able to record an agreement in advance, an agreement that perhaps can be bought out of at a later time. Transactively integrated systems are must be communities of trust to be secure, and traditional integration has no way to establish trust.

Here are some aspects of trust between trusted systems in a transactive community:

• Trusted Control Systems
• Defense in Depth
• Mutual Authentication
• Reputation Management as the component level
• Blocking [component] identity theft, preventing data tampering
• Stopping Denial of Service attacks.
• IOT requires DNS; IoT DNS may need to incorporate trusted systems approaches.

Cryptocurrency and FinTech approaches are likely a part of this. The essence of cryptocurrency is creating distributed consensus databases that are trusted because of the consensus. The IOT may have thousands of transactions per day in even a medium sized house—transaction fees, if required, may be intolerable. This areas is developing rapidly, so choose wisely.

The article "Blockchain’s brilliant approach to cybersecurity" in the references has some interesting speculations in this area.

Money and Markets: digital currency, security, and resilience

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.

When we start a conversation about Transactive Energy, most thoughts go immediately to government-backed currency, such as Dollars or Euros. The second thought may be digital currencies for which there are wide exchanges that can be immediately converted to a government backed currency. I name transactions made using these currencies as bankable transactions, because the proceeds of a sale can be deposited directly into a bank. Large transactive energy markets, such as those for the bulk power market operated in North America by the ISOs and RTOs, have to use bankable transactions.

At the other end of the scale, in a transactive market operating a home microgrid, perhaps entirely off the grid, do not need to ever be bankable. A non-bankable currency is merely an abstract representation of value. My refrigerator is unlikely to be able to buy itself a new water filter based on its day-trading with the air conditioner. I, as the owner, may use nominal dollars to allocate priorities, but that is to make it easier for me to think about priorities, and not to give the paper shredder an allowance. When the currency does not need to be bankable, there is no advantage to using a digital currency that relies on an off-premises cloud.

The real purpose of cryptocurrencies in transactive energy is not to be bankable, but to manage information flows in markets. I use the term cryptocurrency to distance this conversation from blockchain which, while the best known and most well established technology, is not the only one, and whose limitations are right where transactive energy at small scale needs strength.

A cryptocurrency is first of all a distributed database. This database protects its information from meddling by distributing information across multiple systems to create a consensus ledger. Database systems relying on consensus transactions inherently can embrace “lazy commits” and “eventual truth”. (These features are why blockchain in logistics management is a hot topic right now). With the right technology, a cryptocurrency can be support high-performance transactions performed with very small CPUs. Some well-known cryptocurrencies, such as bitcoin, require expensive computations so as to limit counterfeiting and “mining”. If a home were operated using a cryptocurrency market, many transactions would be for less than a penny, and the IoT requires lightweight hardware.

The functions of a cryptocurrency database are identity, contract, transaction, and payment.

Parties must first identify themselves. In Credit Card transactions, a party uses a government supplied ID to establish a banking relationship. A government-issued ID is often required to prove identity for all but the most trivial transactions. The IoT cannot bear such overhead. A cryptocurrency supports establishing a local identity for each party.

Agreements are not enforceable in the world of normal commerce without a contract. A contract may require registration at the court house to be enforceable. Many bitcoin-reliant markets require extensive authentications surrounding an agreement, even within their veil of anonymity. There is no courthouse for the Internet of Things, but a distributed consensus database can provide the next best thing.

Transactions represent the moment that a thing of value is actually exchanged for a promise of payment. This may be in fulfillment of a pre-existing contract, or it may be as a result of actions on the fly. In essence, their needs to be a consensus about meter readings.

Payments, the exchange of coin, must be recorded in the database because being virtual, they have no existence unless recorded.

In the simplest ownership scenarios, there may be no need for the security benefits of a consensus database. In my house, all transfers are from my pocket to my other pocket, and I may not require validation. I may still want a standards-based micromarket to give me access to a wider market of systems, i.e., a community battery system for use in my house, for wider integration options.