How is a Control System like a Database?

"Every Web 2.0 company is ultimately a database company."  Tim O'Reilly

Embedded systems should expose web service interfaces. That web service should be secure or not. That web service should be on a private network or not.

The first generation enterprise interfaces to embedded systems are about cleaning up messes. We got rid of the protocol gunk by moving things to TCP/IP. TCP/IP allows normal routers to pass traffic to and from embedded systems. TCP/IP enables generic service monitors to watch the traffic going to and from an embedded system. We have normalized the lower level functions of the network. That step got us ready for first generation web services.

The first generation web services for embedded systems are about Plain Old XML (POX). First generation web services for Enterprise systems are also about POX. Although we have standardized the serialization strategies, and moved towar4d stateless connections, we are still using the old API (Application Programming Interface) model, requiring the enterprise programmer to have a deep knowledge of the underlying system and its processes.

Even though first generation web services now use an asynchronous protocol (TCP/IP), they are still used to make what are essentially synchronous calls to remote state engines. Do this now. Write information to this register now. Do exactly what I say, when I say it.

First generation web services are characterized by the REST (Representational State Transfer) style of development. REST development uses the 4 verbs of HTTP (POST, GET, PUT and DELETE) to do all programming. Today most enterprise interactions have not grown up into true service oriented architectures (SOA), but are instead procedure-oriented programs connected by URIs. They do no support concurrency, they do not support long-running process. They assume that all calls originated inside the firewall, if not inside the data center, and they therefore use only the simplest concepts of security.

To grow up, web services will have to move beyond simple CRUD (CREATE, READ, UPDATE, DELETE) and into more abstract interactions. But how is a database anything beyond CRUD? Well modern enterprise databases defend their data. They will not let you add records that violate referential integrity. Some records cannot be deleted by certain people. Other records automatically create detailed change logs whenever they are updated. The database is charged with the mission of maintaining referential integrity, and your CRUD is subordinate to that.

I worked a couple years ago with a web programmer who used the latest development tools to work with back-end databases. He would query the tables he wanted from the database first thing in the morning, and manage all changes using his in-memory datasets throughout the day. He felt pretty good that he was using databases at last. But of course, he wasn’t. He had concurrency problem. He had referential integrity problems. He was not using the database, merely writing to it.

If every Web 2.0 Company is ultimately a database company, does it follow that every Web Service 2.0 is ultimately a database interaction? Does it mean that the processes that generate the database, and that the database controls, should be unreachable except through the database? That database should be responsible for all sorts of data, and process integrity issues, just as a mature database is responsible for authorization and auditing functions.

Invisible and Uncontrollable

Recently a reader posed the question, why integrate building systems. He wrote that the primary mission of a building systems is the economic provision of healthful and comfortable space. It is usually run in set and forget mode - and has no interaction with the business processes of the tenants. They remain invisible and uncontrollable unless they break.

Building control systems extend way beyond HVAC. Access control systems should interact with human resources. Intrusion Detection systems should interact with the catering schedule. Medical gas distribution systems should interact with patient care and surgical scheduling systems.

Traditionally we have talked about HVAC first, because of the easy tie between HVAC and energy use, and between energy use and money. Because traditional business models keep the building ignorant of market prices for energy, anything beyond static energy analysis is not rewarded. Because of the lack of standards and insufficient abstraction, there has been no way for business processes to integrate with HVAC. This old-school model is what we find in most buildings today. And within it, the value of integration is limited.

The value of integration can be found in new business models that it enables; these will develop in tandem with the abstract protocols that enable them. Dynamic power grid pricing will create incentives for building responsiveness. Four dollar a gallon energy prices will create incentives for accounting for business decisions that affect when the building is operated. HIPAA compliance requirements will require improved interactions between medical processes and physical access to record storage....and these are not issues that fit neatly into the old business models.

In the future, invisible and uncontrollable will not be good enough.

Still Waiting. . .(part 2)

I have been asked several times recently why we went our own way, away from the standard packaged “Enterprise Energy Management Systems” A few posts ago, I wrote how energy management systems have been pitched to owners and operators.

I still have my response to the salesman’s follow-up email. The vendors name has been removed, well partly out of politeness, but really because, it could have been almost any building automation system vendor, and any presentation – including a few I heard pitched in Chicago three weeks ago.

Dear xxxxxxx,

Your letter tap-dances around the fundamental issue that your system is *not* designed as we have indicated. Please show us the favor of not talking around that. Java does not make something open. ODBC access to pre-digested data does not make something open.

Having said that, your system does provide many very interesting features, features that we have already worked long and hard to get with our current system and includes some that the Energy side of the house really likes. I am positive that with a good deal of work, we could get what we already have. It may be entirely possible that with some small amount of additional effort, we can get beyond that to something marginally better.

The unfortunate truth is that we are already have a system, it does many of the same things, and the likelihood of changing in mid-generation is slim. The system we will change to is one that qualitatively changes and advances the way we can access building systems operating data. This is only going to be achieved by allowing direct unfiltered, un-aggregated access to local data.

We feel quite strongly that this will be achieved when local, shall we say "floor-level" controllers can be accessed as a standard web service. As a term of art, a Web service is "a collection of functions that are packaged as a single entity and published to the network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide."

We are certain, that Web Services are defined in terms of XML and SOAP (http://www.w3.org/TR/SOAP/) expressing standard semantics.

We are telling you, as we have been telling all vendors for the last year, if you want to show us something new, show us XML and SOAP.

When you can show us that, you will have our full and complete attention.

When you can show us that, we will be able to afford to abandon our current working system . When you can show us that, we will be able to let central admin applications compete purely on merit, something [your company] should be poised to do.

Until that time, you can only offer us marginal improvements, even if, as you have described below, you are the supreme implementation of the technology of the 90s.

I am happy to discuss this with you any time. But please do not do us both the disservice of agreeing with me for half a letter, and then describing how your system meets these requirements (architectural, as well as standards) in every way. Please re-read your own writing if you need to understand why the proposal as written is unacceptable (your note contains its own rebuttals on scaling and access). You do the evaluation of your product a disservice by doing so.

tc

I have shared this letter, with identifying information removed as it was here,  with several friends in control companies. Nearly always, the first question was “It wasn’t us, was it?” The sad thing is, I could still write this same letter today, a full five years later. The standards have moved on. Some of the links may be broken. SOA (Service Oriented Architecture) based on SOAP is in place and running the business to business infrastructure of America. Standards are now in place for business transactions and business processes in XML.

But for access to operating information from embedded building control systems, for the ability to coordinate control systems with any sort of high-level directives. . . I’m still waiting.

Discoverable Abstract Interfaces

Interfaces to traditional control systems are concrete and detailed, and therefore their operation is complex; one cannot operate such systems without detailed specific understanding, or what is called domain knowledge. There is often little overlap between different areas of domain knowledge.

My car has a complex control system built using the CAN protocol. I have no knowledge of that protocol. I operate the car using a much simpler abstract interface. The one on the right makes it go faster. The one on the left slows the car down. This dial says how fast it is going. That dial says how much fuel is left. By understanding this abstract high level interface, I can operate any car. My mechanic needs to know the control system – I do not.

Because the interface is abstract, it is discoverable. I can sit in my wife’s car, and in a few minutes understand the differences. The dials are slightly different. My car is manual and hers is automatic. Mine has a tachometer and hers does not. The interfaces support some diversity, but the diversity is within a small range so the details to operate each car can be discovered quickly by the driver.

When I am in the car, I become, in effect, the control system for the car. This system interacts the other driver-car systems using a simple abstract interface based on lights. I use abstract signals to indicate slowing and turning, and the other systems react as driven by the needs of their systems. By using a highly abstract interface, no a priori negotiations between drivers is required to coexist on the same systems bus, or “road”.

Before complex control systems are ready for the enterprise, they must hide their complexity and detailed domain knowledge behind an abstract interface. For that interface to be available to computer systems rather than to people, it must be formatted for machines rather than for people.

And that is what I mean by discoverable abstract interfaces.