Dive in - Systems Surround us like Water

There is a water shortage this summer in central Carolina. As usual, most in the community are in denial and continue in the profligate use of water no matter what they hear on the news. No matter how bad it gets, a significant number of people will worry about their lawns first; they must continue to look like April in August. (N.B. The local climate supports fine healthy lawns with no watering; that’s why the area is known for golf courses.) Most people in this country have never had too little, whether it is too little food or too little comfort. Rarely does any act have any consequences. We find it very difficult to be simply mindful of the resources we use.

One of the local towns has already slipped into early crisis. Of course, there is no pricing and no market discipline; so we use regulations in their stead. Home owners are limited to Odd Even day watering. Most don’t seem to know what days they are permitted to water, or what day to call automatic overnight watering. As someone who grew up in the parched southwest, I find that my lawn, completely un-watered all season, looks pretty green.

Regulations, unlike markets, require police actions. Last week, some 300 people were given warning citations; more than 50 received a second citation and nominal fines. A third violation results in a $500 fine and disconnecting water.

I would guess that most who received warnings did not think there was a serious shortage. How serious can it be if folks can continue to use water to water their lawn? Most of those who received the citations probably have automatic irrigation systems and have no idea how it works, or how they might change it. The irrigation control system interface is obscure and un-informative. The owner of the home has no idea how to re-set it.

It comes down to mindfulness. We don’t care if things are done well, as long as we don’t have to be mindful of them. We don’t know if the yard needs watering, so we automate it and forget it. We don’t know if electricity is scarce this afternoon (100 degrees again), so we just hope that the power company keeps the electricity on. We aren’t sure what might be good to eat, so we go to a chain where we will not be surprised. We do not know want surprises, so we take the family vacation at packaged resorts and parks. We want assured results, so we give everyone in the league trophies. And yet we sign up for yoga classes to become self aware.

Life’s rich tapestry is all around. Noticing life is what makes life worth living. Becoming engaged with life is what makes people mature when they have kids. A life with no information is a barren, boring life. Living with systems that are invisible and uncontrollable is not luxury; it is a poverty of experience and the mind. We need to make out interfaces rich enough, inviting enough, and rewarding enough that we can invite everyone to enjoy life more.

XML is not enough to create an Enterprise Interface

On the NBIMS list yesterday, Louis Hecht with the Open Geospatial Consortium (OGC) observed:

XML does not provide semantics. XML does not solve business problems. XML Schemas do not provide semantics or solve business problems. XML, by itself, does not solve interoperability problems, yet it is an important tool for doing so.

And he was exactly right. Bad XML Schemas, and perhaps most first generation XML schemas do not provide semantics. Good XML schemas implement semantics, bad ones do not. For an example, within the Building space, I would argue the GBXML provides semantics. Even oBIX 1.0, frustrating to me, offers semantics, but one limited to points services and therefore not readily accessible to business functions. Establishing base semantics was a critical early goal of that project.

Good XML Schemas are all about semantics, for without semantics there is no interoperability. I would refer to something like UBL (Universal Business Language) as an overarching semantic framework that is being built into numerous schemas at a deep level.

The larger point is true. XML and XML schema do not inherently include semantics - but the good schema do. One of the reasons that I am watching NBIMS so closely from the oBIX vantage point is that the higher semantics will need to be there before oBIX has an enterprise interface. I have a hard time imagining what applying Policy to point services even means. Our next challenge is to figure out how oBIX accepts an ICAL invitation to make the building system "occupant aware".

As Enterprise programmers will never be control engineers, we are going to have to wrap up the standard functions into business services. In oBIX if I define a set of functionalities for a given period of time, it is called a contract. For these to be useful, we will need to pre-define several contracts and make each of them discoverable. Discovery will mean that we need to describe each one in terms of the service it provides. The Description/Catalogue will need to be machine readable rather than human readable, which means it will be based on Semantics.

But whose semantics?

I am hoping we can find a way to map Design Intents / Systems modeled by the energy model / spaces served into Service descriptions. It would make sense, then, to invite the control system's Service to the same meeting. To do that, to make a Service that can be subject to Policy, that can have rational Security applied, that can be Discovered by enterprise applications will require that we have Semantics embedded in the XML of the Service Descriptions.

It is still my plan that as I become more familiar with NBIMS, I will be able to discover the Semantics I need to do this. Somewhere in the check list of Services to be Commissioned, in the Systems in the Energy Model, and even in the Function analyzed by the Code Compliance checker are the Semantics needed to create discoverable abstract services.

And that XML will be an order of magnitude more useful because it is semantically laden.

Got an idea on how we can bring semantics  to building systems XML  - please post a comment...

AMI doesn’t make much difference without fundamental process change

Few changes in the utility industries have generated more interest and discussion that Automated Meter Information (AMI). AMI is the ability to get digital readings from [electric] meters at a distance. Industry articles tout AMI as “the biggest change since….” In most cases these, articles are wrong. Too many plans for AMI were designed to prevent any fundamental change, and so end up merely paving the cow paths.

I began my career in information technology working in and around Boston. Local legend has it that the original paths between the scattered houses of the settlement of Boston were made by wandering milk cows as they neandered from barn to field.

People naturally walk along cow paths. The brush has been cleared and the way is smooth and packed. As the town grew, these paths were preserved as the roads were cobbled and then paved. The result is the winding mess of roads surrounding Milk Street in Boston’s downtown today.

Paving the cow paths is a classic source of failure in system design and a common pitfall of business process management. It is my sense that undue respect for preserving the cow paths is a significant cause of the failure of many large Enterprise Resource Planning (ERP) systems.

Universities have one of the lowest success rates in implementing ERP. Universities have an undue respect for the value of the way they have always done things. Universities run many businesses they have no idea how to run well; business managers have no respect for transparency or consistency even within their fiefdoms. At UNC, the new ERP project is already in trouble as units try to preserve the Carolina Way they have always done things. (Guys, let it go! If we really liked the old way of doing business, we wouldn’t have needed to buy a new one.) Some of my readers have observed this process within their own organizations.

Utility companies, used to state regulation of their business processes, and focused more on possible failure than potential success, make many of the same mistakes. By focusing almost exclusively on preserving and optimizing their pre-existing business processes, they are missing the transformative benefits of AMI. AMI is about driving slowly through the neighborhood once a month and having all meter readings without a single dog bite. In many areas, customers are by policy blocked from direct access to their own meter information because they might “misunderstand” or “misuse” it.

The real benefits of AMI stem from transparent immediate access to meter data by both the buyer and the seller. This information will create and drive new markets when it is also available to the buyer’s agents, including third party auditors and building systems operations specialists as well.

Human readable mechanisms are not enough. Personal web pages to get to your own meter data through the utility central office are designed to impede live response. Digital read-outs on the thermostat do not enable the buyer to develop their own automation strategies. We must demand that full information be computer accessible inside as well outside the building. All information formats should be compliant with e-commerce style standards. Only by doing so will the new mechanism for demand response flourish; only then will full markets for managing load flourish.

Transformation through Interoperability

I just got through reading some conference abstracts on energy reliability and demand reduction. Every paper brought intelligence and a deep domain knowledge to the subjects. Still, there were big differences between them.

The basic approaches are well understood and widely known. Your parents or grandparents, whichever generation it was that grew up in the depression told you all the key techniques of demand reduction when you were growing up. Turn off that light when you leave the room. Don’t run that water. Eat everything on your plate. Well, maybe not that last one. Under demand reduction, we merely automate these processes.

Power reliability is also well understood. There has been little fundamental change in the power grid design since the 40’s. The sensors have gotten better. The power crews now use cell phones with GPS. The standard is still for how many minutes a year I can light a light bulb.

Engineers are process oriented. Processes are about situation awareness and predictable results. Good engineers extend control over processes to increase predictability and reliability. Digital control has enabled good to extend and automate control of demand response and power reliability. Sometimes a technology like Zigbee comes in and gives the engineer a new tool to cost effectively extend sensing beyond where he could before, or in a more cost effective way than before. Most of the papers I read showed good engineers making incremental improvements to existing processes.

Real change is rarer. Real change comes when someone recognizes that the last incremental change enables doing something quite different. Often the engineer who develops that change does not recognize the value of his work. And so we plod along, getting another 1-2% efficiency at the cost of great effort.

So it is in building-based energy management, and in managing power reliability. Power grid operators who have long used demand response on the supply side are wrapping old fashioned energy management in the same old blanket. Some energy suppliers are beginning to discover what their customers have been doing since the energy shocks of the 70’s. This will result in another incremental improvement.

We need something better than incremental improvements right now. We cannot afford the power grid incremental improvement will demand. We will not stand for building the transmission lines and power plants incremental improvement will require. We must look for a transformation, for something that changes the rules.

The rules today are that energy customers, the buildings, are passive consumers of power. The rules today are that the Utility is responsible for providing as much energy as the building wants at whatever time the building wants it. The rules today are that members of a Utilities Commission, experts in neither power provision nor efficient operation, will decide on all innovations in society’s “best interest”. All the incremental improvements work within these rules.

We must use information technology to break these rules, not merely to enforce them with incremental change.

Using information technology, buildings and neighborhoods can be responsible for their own power use, and even power generation. These needs can be informed by the operations of the homes and businesses in those buildings. This can free up the Utility to be a source of power for homes, but not the only one. The utility can use information technology to focus on efficient delivery of energy; freed from the burden of instant response, it can make radical improvements in the efficiency thereof. Using information technology, building occupants will negotiate with their internal processes and with the power grid using instantaneous knowledge of the most powerful abstraction in the economy, pricing.

The transformation comes from trading the efficiency of control communications for the nimbleness of abstract interfaces built on open standards. In the grid, this will remove structural disincentives to new power sources, including “unreliable” ones based upon natural forces such as sun or wind. In the building, this remove the complexity of assembling diverse sources of on-site power generation and storage while enabling energy using processes to be responsive to the needs of the human inhabitants and current power availability as indicated by the live prices.

This transformation will make more of a difference than all of the incremental changes, even as its details will use and extend the craft learned through the incremental changes of the past. This transformation will only come from giving up control, and allowing interoperability.