The Agent Personalities

The Lab relies on each system or group of systems being represented by an autonomous merchant agent that buys or sells Power for those systems. The software for this agent is Open Source and can be freely downloaded for use in products. As described in Dr. Cox’s blog on the architecture, this merchant actor interacts with the actual systems and controls through an abstraction layer.

While there is a simplicity in a single Agent, we think there are benefits to creating more than one type of agent. A single agent running a single set of code could encompass all behaviors could be created. It would also increase the size and complexity of any agent.

A profiled agent that is optimized for specific types of market behavior can be smaller and more secure. Naming similar market behaviors across systems makes it easier for the integrator to understand how introducing an additional system will affect an existing micromarket/microgrid. We name these the Agent Personalities.

The Agent Personalities

Each Agent Personality denotes a common set of market behaviors.

Homeostasis Agent

A homeostasis agent represents a system that consumes power episodically to support it’s a purpose external to the resource market. A homeostatic agent schedules power purchases to support providing a service that is not known to the grid.

Two examples of systems that would use a Homeostatic Agent are an air conditioning system and a refrigerator. Each of them buys power to support processes that support a service external to the grid. Neither wants to run unless it is able to buy the entire power curve it needs for its next cycle. Each could advance or delay its purchases to some, or even skip a cycle, without harming the service it provides.

Preconsumption Agent

A pre-consumption agent is similar to the homeostatic agent, but it provides an asynchronous server and therefore has a bias to buying only when the price is low. The system is able to increase consumption in the short term to enhance its ability to provide service at a future time. If the refrigerator is a homeostatic agent, the ice-maker may be a pre-consumption agent. There may be overrides to the behavior, i.e., fill up before the party, or high priority when less than a quarter full.

Base Consumer

Base Consumer uses power continuously when the system it represents is providing a service. An example is a light which is either lit, and consuming power, or is unlit and not consuming power. An agent representing one or many lightbulbs on a circuit changes in scale only. A base consumer is almost always a high-priority purchaser in the market.

Tiered Consumer

A Tiered Consumer differs from a Base Consumer in that it may be able to reduce power consumption by providing a lower level of services. An example is a dimmable light. More power might provide a better service, or a different service. Using for example the dimmable light again, a low level of light might support movement, a high level of light support reading, and a higher level of light support personal grooming.

Base Supplier

A Base Supplier supplies power continuously. A Base Supplier might include any controllable generator with a long cycle time. Long cycle time is situationally defined.

Market-Driven Supplier

A Market Driven Supplier supplies power intermittently, based on interactions within the microgrid.

Intermittent Supplier

An Intermittent Market Supplier supplies power intermittently, based upon inputs external to the microgrid. An example is a photovoltaic system, which generates power when the sun shines.

Storage Agent

A Storage Agent is able to consume resources later supply the same resource. It stores power. This is similar to a system able to pre-consume, but it is able to bring some portion of its pre-consumption back to the market at a later time.

The Platform Agents

Any of the Agents Personalities named above can in principal interact with any other agent through bilateral transactions. Some markets might be set up with all tenders going to a single entity who manages all transactions.

Broker

The Broker acts as an agent by executing public orders. It may operate a double auction. The Broker does not itself have a position in any trade. (Transactions to power the broker are an exception). In the home, a home router may act as a broker.

Market Maker

A Market Maker acts as a Broker by executing public orders left. It Market Maker further maintains an orderly resource market with a responsibility to buy for its own account in the absence of public buy orders, and sell from its own account in the absence of public sell orders. The market Maker personality may be associated with Storage or with external market sales and purchases. External market sales and purchases are not part of the internal maker that operates the microgrid.

How to use the Agents

Each of the simple agent personalities could characterize a single node or a collection of nodes. Microgrids can be characterized just as nodes are characterized. This point is fundamental to considering interactions within aggregations of microgrids, as to considering the dis-aggregation if a node into smaller component systems.

A system or device developer should select the personality that he desires to represent his technology.

A set of agents sufficient to support systems with each of these characteristics is able to support all systems potentially within a microgrid. Such a set does not rule out potential hybrid systems, in which two or more of these characteristics coexist within a single system—such a system is a natural outcome of a microgrid at one level being a node at a higher level.

IoT Apps and Competition for Resources

This week I am talking about a Resource Framework for the Internet of Things (IoT) at the summit of the AllSeen Alliance.

Traditional consumer programming has concerned itself with only a few resources, i.e., RAM (memory), storage (disk space), and communication (network speed). These programs live atop operating systems and device drivers that engage directly with physical things.

Third-wave Apps in the IoT, though, deal directly with resources. The second wave of the IoT, what I call the Internet of Sensors, may measure resources, but Apps are not competing for resources except, perhaps, bandwidth to report them. Two measurements of air temperature do not compete. And one does not “use up” the temperature that the other one wants.

Third-wave IoT Apps do things, and can only do things to the extent that have access to resources. Resources may be electrical power or heat or water or water pressure, or anything that the systems controlled by an App need to support their purposes.

Some resources exist as a fixed pool that is then drained over time. Other resources may have a steady supply over time. As other IoT Apps require the same resources, the size of the pool varies not by the schedule of its own ebb and flow (think power provided by Solar PV), but the supply changes as other Apps consume the same resources, or perhaps can even be induced to supply more of that resource. Resource availability, the net of supply and demand, is always changing over time.

With a predictable budget for a given resource at any moment in time, Apps must avoid interfering with each other. Sometime this is a competition, but often it may be as simple as avoiding the time that other Apps are using the same resource. Two Apps that use the same resource at the same time may both fail if there is a shortage of resources adequate for simultaneous operation. This is a problem of a moment in time. If one can delay its operation, or the other can accelerate its operation, they may be able to perform all functions, to get access to all of the resource each needs, by simply avoiding each other.

Traditional solutions to this problem posit a master controller, a single controlling program that understands each application and its needs. This works best when all systems and apps are provided by the same manufacturer, and the systems work together as slaves do: on command, as directed, and interchangeably.

With a resource framework, we hope to define a framework within which Apps in the same space can negotiate for resources over time. We can use the specifications built for Smart Energy and The Lab, to negotiate power use and supply, for other commodities as well.

Enabling Energy Mashups

I’ll describe energy mashups in detail in upcoming posts. For now, think of systems of systems that dynamically, self-assemble and reassemble as needs change. Many more ideas (and links) will be in future posts.

Staying abstract for the moment, an Actor in the EML world has two concentric shells surrounding it. The Actor is your device, system, or system of systems—say a microgrid, an appliance, a building, or an HVAC unit—and is entirely your business....

Read More

Welcome to The Energy Mashup Lab

After nearly two years of work, The Energy Mashup Lab is creaking into public operation. Since Dave Cohen and I initially sketched out its activities in the Fall of 2013, we have been putting the pieces together. William Cox joined us in 2014. Our goal is open source software agents for self-assembling microgrids...

Read More