Getting from Registers to Ontologies

Control programming today is like writing device drivers. Internal to a computer, low level programming is about moving data in and out of internal registers. Control system programming is, for the most part, reading and setting remote points. oBIX 1.0, first and foremost, provides point services for setting, reading, and tracking remote control systems. By defining a web-services based pattern for accessing the point service, control systems have been made accessible to enterprise systems and to enterprise programmers. Point services are not, however, enterprise friendly.

In almost all creation myths, the first task of man is the naming of things. We call formal rules for naming of things “semantics”. The next task for oBIX is to move to formal semantics of embedded systems. There are three approaches we could follow for semantics: tagging, system, and service.

Tagging is the most traditional naming for control systems. Tags are merely the naming of each point. Tags may appear on the initial schematic diagram of the control system. There may be some sort of internal logic to tagging. CWCRT007 may be the Chilled Water Coil Return Temperature #7. I might just as easily use the tag CWC007RT for the Chilled Water Coil 7 return temperature. The control system integrator assigns tags within control systems. If I am lucky, the integrator working on the third floor will use a naming convention compatible with that used by the man working on the sixth floor. If I am an advanced owner, I might have specified the standard to be used pre-construction. Tag standards such as these do little to help the enterprise work with multiple buildings.

System based semantics will name things by the system they are part of. This approach aligns well with the data life cycle defined by NBIMS (National Building Information Model Standard), especially if the contractor uses COBIE (Common Operation Building Information Exchange) to hand over NBIIMS information to maintenance and operations. Each system gets the same name it had on the initial design documents. One problem with this approach is that most design documents have significant errors and duplication in the controls portions. These names, while useful to those performing maintenance on the building, they often have little to do with how the tenants see the building, and thus may be difficult for enterprise programmers to use.

Service-based semantics name systems for what they do, not what they are made of. Service-based semantics may be mapped to the spaces they support, i.e., “Heating and Cooling for Big Conference Room”. This makes it easy to link business processes with building processes; we can easily imagine inviting the heating and cooling system to the big meeting. It may require additional maintenance, as the C-level executive’s office, however critical, may move from one room to another.

Ontologies are the next step above semantics. Ontologies are the classifications that semantics fit into. A computer-based ontology would enable a computer to fit a system into one or several hierarchies of meaning. To illustrate, consider a room in which a cat is playing. I ask the computer, “Are there any animals present?” Using semantics, a cat is not an animal, and the answer is “No”. Using an ontology, the system considers that a Cat is a type of Pet and a type of Mammal. A Mammal is recognized as a type of Animal. Now the computer can answer, correctly, yes.

Today, we talk of the interactive web, and call it Web 2.0. Web 2.0 is interactive and responsive in ways that the initial internet was not. Small point services add increased functionality such as the type-ahead and spell-check functions in Gmail. Current discussions of the future of the internet imagine systems being able to negotiate with multiple remote web sites to increase function and responsiveness. These functions may include discovering new remote service on the fly to respond to user or system requests. These new functions will require that systems be able to recognize and understand the services provided by remote systems. The basis of Web 3.0 will be the formal ontological classification of web services.

Service-based semantics provide a better basis for ontologies than do system-based or tag based semantics. A single system may provide more than one service. Each service may be linked to multiple chains of ontology, just as the cat above is linked to both the “Pet” and the “Mammal” ontological hierarchies. A single service may be linked to both an external standards-based ontology and an internal organization-based ontology.

All of this sounds at first hearing as a bit of a stretch, but in the near time, it will become the basis of what we expect from all system integrations. Interested readers may wish to check out Ontolog ( http://ontolog.cim3.net/ ), a Web 2.0 home for those exploring how to find meaning (ontology) in engineered systems.

Corporate Transparency and Energy Boondoggles.

There is an abstract interface already in place that most of us understand. It communicates scarcity and abundance. It allocates resources over time. It relays the comparative worth of alternate solutions. We call the interface “the economy” and we call the abstractions “money”.

When we interfere with the prices in the economy, we are deliberately miscommunicating value and scarcity. When we deliberately falsify communications, people will make the wrong decisions. Those decisions will be bad for the economy, bad for resource allocation, and bad, in the long term, for the person making those decisions.

I wrote last week (other-peoples-money-and-poor-decisions.html) of a proposed program in Wilmington, Delaware to offer reduced electrical rates for 5 years to new businesses setting up shop in the area. Each of these businesses is wasting time by putting off developing new business processes that use less energy. These businesses have self-identified themselves as being among those most in need of new processes by relocating to take advantage of the deal.

As a country, we have dedicated a lot of effort toward transparency in corporate governance. Many of the rules are bound in the Sarbanes-Oxley (SarBox) legislation and the resulting regulation. The aim of these rules is to require corporate officers to take responsibility for full and honest reporting of business practices and potential liabilities. The spirit, if not the letter, of the law should require these businesses to report their strategic failures and the anticipated costs of ignoring true energy pricing.

Most likely, the corporate officers will award themselves bonuses for short term profit goals, and be long gone before the costs of their decisions become visible. The activists who might be expected to protest will be blinded by the fulfillment of their progressive fantasies of job creation. And all of us will pay in continued high energy use, subsidized by the muddy thinkers of Wilmington, Delaware. Bad information leads to bad actions. Fully transparent pricing for electricity is the basis upon which good decisions can be made.

Technology has given us an historic opportunity for transparent energy markets. The Energy Bill of 2005 has spread the enabling mechanism of time of day metering across the country. We can now apply the most commonly accepted abstract interface to time of day allocation of energy resources. We should get past politics as usual to take advantage of it.

AMR, AMI, and Autonomy

Automated Metering is one of the critical for changing how we think about and use electricity, both within and outside buildings. Sean Dempsey pointed out ( /articles/ami-doesnt-make-much-difference-without-fundamental-process-.html ) that I had elided AMR (Automated Meter Reading) and AMI (Advanced Metering Infrastructure. AMR is simply automating the old meter reading process, reducing head counts and reducing dog bites, but not essentially different from old processes. AMI (Advanced Metering Infrastructure) refers to more advanced systems that enable dynamic pricing mechanisms, new payment and customer service options, and control of electrical loads within the home. One source of confusion is what the electric companies are actually doing. Many utilities are installing AMI-capable equipment to support AMR.

Not even AMI, as usually implemented, fundamentally changes the traditional relationship between buildings and the grid. Neither process puts the building inhabitant, whether home or business, in control. Neither one creates the change in markets and attitudes that will create fact-based building operations. Fact-based building operations will create the open markets needed to power innovation. Without control by the inhabitants, fact-based operations will not create sustainable drivers of market-based innovation.

The information of AMI must be accessible in real time and fully trusted by both the power company and the building inhabitant. Rights to AMI information and control must be securely assignable to whatever agents the inhabitant chooses.

The power company must not have privileged position in managing the facility. The power companies interests are not and never will be aligned with the desire for maximum amenity and control desired by the inhabitant. The power company’s interest is in maximizing its own revenue by eliminating peaks; it will never have a strong interest in limiting off-peak demand. That is as it should be.

The inhabitant, of the building, whether a home owner or a business, should be in charge of the buildings responses to the information made available through AMI. The building inhabitants will be the customers for diverse markets in demand response and price reaction. Building inhabitants will have the proper incentives to manage the overall economic and reliable provision of power-based services. Building inhabitants will be the market for integrating local power storage, on-site generation, and time-based energy purchases. Electric companies can only commit to technologies guaranteed no to fail in large scale installation; building habits can afford to gamble on innovation.

The inhabitant may choose to mange this internal energy portfolio internally. The inhabitant may choose to outsource this portfolio management to any of a number of vendors which already have a connection to the building, from industries such as telecommunications, or home security, or cable. The inhabitant may even decide to let the power company bid on providing these services.

What would you do if you had full access to your own AMI infrastructure?

Why The Enterprise needs Building System Information

Just about all the low level systems claim they have an interface to The Enterprise. What they have done is expose the low level engineer points within each system using the XML used by Enterprise systems. For the claims to be honest, they need to bundle up these low level points into the services they provide for the enterprise and expose those services as XML.

The Enterprise is, quite simply, the normal business of a corporation or agency. The Enterprise includes all the ways a business makes money. Anything that does not make money should have its costs cut.

On the edge of the enterprise are what some have called “hygiene factors”. No one is hired for their hygiene, although people have been fired for neglecting it. A cottage in the country can get by with an outhouse; but a town that does not upgrade its hygiene requirements as it grows smells bad. Hygiene factors are necessary, but rarely thought of.

Today Building Automation Control Systems (BACS), with a few exceptions such as pharmaceutical verified environment systems, is little more than a hygiene factor. As such, its operations are relegated to the dankest room in the back office, with little respect, outsourced if possible. It is noticed only when it fails (and perhaps by the odor). Enterprises certainly do not manage BACS as a strategic asset.

Health & safety concerns, Sustainable Buildings, and Carbon Credits are beginning to get BACS recognized as a strategic asset. Quality of Services (QOS) requirements are increasingly being written into leases, not only for comfort control but also for power management, HIPPA compliance, and other issues..

But what can control systems provide to the enterprise? Here is an example:

There is no building system simpler to consider than the black mat at the store that, when stepped upon, opens a door. A large retailer has enterprise enabled its door openers to provide live foot traffic information to its sales staffing operations. This information is used by its advertising and marketing groups to analyze the direct effects of their activities. A simple convenience control with very little smarts is now a corporate asset to three separate enterprise activities. Providing access to user friendly information enables people to make better decisions.

Today, much of the information available about our building and utility systems is generated for a specific user group focused on a narrow area of interest. The data is provided at a level of detail, and in a terminology, that is not useful to outside audiences.

Putting in place monitoring and information systems that expand opportunities for access and analysis would improve communication and decision making across a range of operational and business departments and users. These must not require that enterprise programmers learn about the building systems. The building systems must share their information in ways that make sense to the rest of the business.