Packing Peanuts and Corn Ethanol

It is hard to figure out the full cost of the government’s corn ethanol mania. Random observations during the holiday season suggest that they are still larger even than reported already. A full accounting, if it were possible, would sound a cautionary note as a new congress and a new administration consider how to stimulate new energy and E-Tech.

The most believable numbers suggest that the full production costs of corn ethanol use more oil-based energy then it replaces. These numbers are of course, in dispute as they include assumptions about fertilizer production and tractor driving and a twisted maze of hiddensubsidies. Holiday packing peanuts are part of the picture.

A notable facet of this century’s world economy has been the entry of the poorest of the poor into the world economy. We have seen this in reports of cell phones in rural India and cell-phone banking in Africa. Driven by Corn Ethanol, food costs around the world skyrocketed. Worried about feeding their families, third world famers retreated from market crops and returned to subsistence farming. As the first world economies stumble, and consumers reduce their purchases, the emerging economies, now cash poor, cannot buy. The world economy, like our crops, has been made more brittle and one-dimensional.

Some problems may be masked as political rather than non-economic costs. There were riots in Mexico, where staple tortillas were priced out of reach. The resulting growing desperation may have recruited more to the drug armies fighting it out with Federales and the police, so much reported this last year. If so, this problem may outlast the short-term corn prices.

Every year at Christmas, I receive boxes from my large family spread across the country. Many of these boxes are professionally packed by the package stores, placed in branded boxes, and packed in commodity supplies. For the last few years, these boxes have been filled with biodegradable packing peanuts, made from expanded corn starch. This year, every such box was filled with plastic peanuts. Corn Ethanol has apparently been a boon to the petrochemical plastic peanut industry, as it priced competitors out of the market.

Christmas is always a time in which the family purchases more pre-made food. Whether for a convenient meal for the family re-gathered or for a special side dish or desert to augment a holiday meal, or even for a quick meal grabbed to allow time for holiday errands, I have performed my annual longitudinal survey of the food containers in local use. For the last few years, these containers have been increasingly made of a corn starch-based polymer that degrades in a host compost pile. This year they were once again, as they were five years ago, plastic.

I hope we will learn from this that good intentions are not enough. I hope that we will learn from this that one-dimensional approaches to sustainability may be less sustainable than their predecessors.

I hope that as we re-make energy markets, we eschew the hubris of central planning.

I hope we have the self discipline to resist the easy answer. We need better markets, and less central planning. This is too important to make the same mistakes again.

A pricing Service for Electricity

What price structures are necessary to enable fully symmetric negotiations over power purchase and sale? Over at the NIST TWIKI, Marty Burns, Bill Cox, and I ironed out the requirements for a pricing service for electricity. Comments are welcome.

---

What are the requirements for communicating price across the smart grid? What pricing structures are in use or under development now? How do we move to a common information element, common whatever else needed for prices?

Note: It is important to emphasize that these are requirements for a solution set for pricing services. Therefore all the following requirements are not necessarily simultaneously applied to any particular single service based on the ensuing model.

Due to potentially [rapidly] changing roles, we use the terms supplier and consumer rather than utility and customer. With aggregators, these terms are still more general.

This page was created and modified by Marty Burns, Toby Considine, and William Cox, for discussion among the DEWGs.

Pricing Requirements

Dynamic pricing enables dynamic power management and includes both:

1) the realtime response of automation systems to "realtime" grid pricing and

2) the managed response of consumer management and planning systems to supplier/grid price forecasts.

1.1 Regulatory/Policy

• 1.1.1 Metering, Billing, and Collections are separate processes / services from power delivery.
• 1.1.2 Aggregation and Delegation should be explicitly permitted for all operations.
• 1.1.3 The pricing model is not explicitly tied to any particular regulatory environment.
• 1.1.4 Barriers to symmetric operations should be eliminated.
  • 1.1.4.1 Suppliers and consumers may exchange roles at frequent intervals.
• 1.1.5 Businesses willl handle traditional business processes as they do now.

1.2 Business Objectives

• 1.2.1 Suppliers are able to provide automated dynamic pricing information to consumers.
• 1.2.2 Pricing is able to support active power management and optimization.
  • 1.2.2.1 Price adjustments can be made in time in up near real time manner.
  • 1.2.2.2 Prices may include commitment enforcement in support of a variety of scenarios, including both minimum and maximum commitments.
• 1.2.3 Pricing should be available for a variety of deliverables.
  • 1.2.3.1 Power Consumption.
  • 1.2.3.2 Peak Availability.
  • 1.2.3.3 Relinquishment of prior right (Differential Behavior vs Absolute Consumption).
  • 1.2.3.4 Power Quality.
  • 1.2.3.5 Carbon Offsets.
  • 1.2.3.6 Transmission and Congestion.
• 1.2.4 Pricing should support the decommoditization of power.
  • 1.2.4.1 Wind, Distance, Carbon, Triple Bottom Line, and other attributes.
• 1.2.5 Pricing should be time sensitive.
  • 1.2.5.1 Time offer made.
  • 1.2.5.2 Window for offer.
  • 1.2.5.3 Time of acceptance.
  • 1.2.5.4 Scheduled Time of consumption.
  • 1.2.5.5 Actual Time of Aggregation.

1.3 Business Procedures

• 1.3.1 A set of core processes and transactions will be defined.
• 1.3.2 A service to support each core process will be defined.
• 1.3.3 A common service framework will be defined to support all services.
• 1.3.4 Market operations should support unidirectional price announcements.
• 1.3.5 Market operations should support bidirectional bidding.

1.4 Business Context

• 1.4.1 Legacy pricing models need not be supported by the new interfaces.
• 1.4.2 Legacy business processes need not flow through new interfaces.
• 1.4.3 Requirements to continue traditional business processes may be met outside of the new interface.

1.5 Semantic Understanding

• 1.5.1 Must accommodate wide range of Pricing Models.
• 1.5.2 All Pricing Models should contain a common set of properties.
• 1.5.3 Many Pricing Models may be in effect concurrently.
• 1.5.4 Pricing Models will change over time and must be discoverable.

1.6 Interaction Model.

• 1.6.1 All intereactions will be messaging based.
  • 1.6.1.1 synchronous request-response pull.
  • 1.6.1.2 asynchronous publish-subscribe push.
• 1.6.2 Symmetry should be supported at all interfaces.
• 1.6.3 Best Efforts message delivery shall be supported.
• 1.6.4 Security and Privacy must be designed into the model.
  • 1.6.4.1 Authentication is often required.
  • 1.6.4.2 Guaranteed message delivery shall be supported.
  • 1.6.4.3 Non-repudiated message delivery shall be supported.
  • 1.6.4.4 Private message delivery shall be supported.
• 1.6.5 Delegation of message handling shall be supported.

Gamboling through the Clouds

Some months ago, I wrote about how Software as a Service (SaaS) was going to be used in building controls. The UNC Enterprise Building Management System (EBMS) and Hosted Controls already use that model for monitoring and operations of building systems. Others like Sensus offer building analytics and knowledge-based maintenance from their own data center. Now Harrah’s Entertainment, the largest of the casino operators is moving into the clouds, and the outcome may change building systems again.

It has been best practice for a while now to interface building systems to hotel customer operations. The check-in process can activate the room systems, which then save energy when not rented. Front door access control sensors can read the room key and turn on the room conditioning as the guest comes in the front door. The Hotel Technology Next Generation group has even included remembering customer preferences for the operation of room based systems in their customer retention strategies. Traditionally, these approaches relied on direct interaction with the reservations system.

Harrah’s has outsourced its systems for managing reservations, for air travel, and for player relations to the SaaS vendor SalesForce.com. This is a strong statement, as no industry relies more on customer loyalty programs than the gaming industry, and Harrah’s is known for the most data intensive approach to this problem.

One of the concerns with outsourcing core business functions like this is vendor lock-in; you have committed yourself to integrating your other business functions with an external computing resource of which you have no control. It is easy to view these operations as a simple user interface for the customer making a reservation, and for the clerk checking the customer in. The hotel reservation has a host of interactions, however. Housekeeping needs to know not only when the customer arrives and departs, but also any requirements for special bedding, or extra towels. The restaurant may support one free drink on the night of check-in; tabs for breakfast on the departure date may need expedited processing. In today’s hotel, third parties may run housekeeping and the restaurant, increasing the complexity of the interaction

These interactions, and their importance to the enterprise, are why service interfaces and service definitions are so important.

If we take these interactions to building maintenance and operations, and to new energy markets, the service interaction problems continue. The reservation process should drive the operation of each room. The hotelier may want to balance spreading guests out for maximum privacy vs. bunching guests on a few floors because of anticipated high energy costs or energy reliability signals. Organizations such as Harrah’s demand close integration of tenant service and physical security.

Harrah’s provides high amenity facilities wherein an extra feel of luxury creates an increased willingness to gamble. Harrah’s has global distribution with considerable site-based diversity. Knowledge based maintenance and central management of facility quality are particularly valuable to Harrah’s.

Standard service definitions can put all operations into cloud computing, whether the low hanging fog of facility operations or the core customer relationship management that Harrah’s has outsourced. Building controls are grounded concrete systems—but their heads should be in the clouds.

Smartgrid Basics: The Demand Side Problem

Last week the Smartgrid-discuss group opened up within OASIS, introducing power grid technologies to the architects of e-commerce and internet security standards. Some of the latter are trying to understand the problem, and learn the jargon. I wrote this as the second of a series of posts introduce the issues in a simplified, almost cartoon form.

Building systems have traditionally been invisible and uncontrollable. They have been managed to reduce costs with no real focus on the service they are providing. They have grown up in sandboxes, using their own peculiar protocols. These protocols are deep and technology specific, and often without effective interface. These systems are operated, when they are operated by process specialists.

Building occupants rarely have a precise understanding of how these systems affect their business. They may know exactly what a too-hot or too-cold call costs. They know that tenant dissatisfaction may lead to un-renewed leases. They may suspect that under ventilation may lead to sleepy occupants, but can rarely put any exact price tag on that. This makes them conservative about making changes in building operations.

Demand Response (DR) is emerging a critical tool for dealing with peak load management. Peak loads are by far the most expensive and dirtiest electricity we have; their costs, on both bottom lines, swamping others. Demand response is moving from direct control to economic incentives, but underneath, today’s integrations are process centric rather than service oriented. Energy providers order or pay energy customers to turn off things on just a few days a year, to manage the peak. We encourage only the crudest, least effective energy savings, while denying the market the energy signals that would cause better.

At the commodity system level, DR is already moving to services and agents. Agents defend their own mission while responding to the outside world. Washing machines know not to respond to grid signals until they determine that the current laundry is not soaking in bleach. Refrigerators know not to respond if they have just finished a defrost cycle. These systems know and understand what services they provide and so are ready to be responsive. Building systems are not.

We will get larger DR when we talk to the building occupant. We will get better participation when the occupant remains in control. The occupant will not allow DR when the in-laws are coming for the weekend. The occupant knows the family overspent at Christmas and is willing to respond to any and all incentives. The access control system may know that only three people on the fourth floor came to work today. Human resources knows that the sales force is on a retreat. Together, they can choreograph far greater response from the building systems then ever will be permitted as an automatic response from control communications.

Demand Response must be about economic signals to a business entity. When thought of in this way, there is no need for different signals to Industry and to Business (and to home and to vehicle). The business may choose to automate this. The business may benefit from templates for response, whether developed by EPRI or by ASHRAE, which reduce the risk of considering participation. These choices and these templates are not part of the interface.

The interface should not does not concern itself with the underlying technology and control protocols. It should not be based upon BACnet, or OPC, or LON any number of other low level control system protocols. The interface must be one that enables business decisions. Control systems should offer up service interfaces for choreographed response. Whatever offer and counter offer DR requires, whether amount of load shed or maximum load used or time to respond must be in the interface, but no deep process.

The smartgrid to building/industry/home interface is about how the Service Oriented Building can respond to the Service Oriented Grid. Just as in other services, the underlying processes should be hidden.

If you want to join the public discussion at OASIS, send a message to smartgrid-discuss-subscribe@lists.oasis-open.org.