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.

Let's Make Energy Models Relevant

Energy modeling is an important part of designing more performant and healthful buildings. Energy modeling is a foundational requirement of important initiatives such as the Zero Energy Building Initiative (link) or the Zero Net Carbon Building project (link). Building Energy Modeling is also an important tool to determine problems in building design before the more expensive construction process begins. Today, because of lack of integration and a reluctance to re-think the design-build process, Energy Modeling is often an ineffective sop to public constituencies, adding cost but little value to a project. This is particularly true for construction projects performed by government agencies, with their commitment to traditional processes and metrics that are often in conflict with innovation and new business processes.

New building projects have two sources of design constraints: organizational goals and design intents. Organizational goals are larger than any single project, and stem often from public pronouncements. All new buildings will be at least LEED Silver. Each new office building will have an energy budget 20% below that of our existing portfolio when it comes on line. Design intents are transcribed for each building, often during marathon charrettes with lots of soggy deli take-out. Together they describe the success points against which the design should be evaluated.

Many of today’s energy models are generated in response to organizational intents. Energy models are a source of green points, and they may have some tangential applicability to the construction documents. They are rarely an intrinsic part of the design process. They are often a sub-contract let by the design firm.

It is more useful to think of Energy Modeling as an audit or commissioning process applied to the design. Just as we wish to commission a building before we accept occupancy, we should commission the design before we bring it to bid. Just as we commission a building to see if it works as designed, we should commission the design to see if it has met the organizational goals and design intents. The energy model is one part of commissioning the design, and as an audit, it may be best be performed by a third party working for the owner rather than the designer.

Often the sole real liability for the designer pre-construction is meeting the bidding budget. If this constraint is not met, we return to the designer for the misnamed “value engineering”. A better process, based upon a persistent building model, would re-subject all value engineered designs to energy modeling as well as the other design validation processes currently being developed [1] . These models would then present explicitly to the owner the compromises to design intent and organizational goals that derive from the value engineering process.

This increased liability on the designer will not come without cost. Increased liability demands increased payment for increased value. This increased cost will be easy to recapture. Errors are always easiest and cheapest to fix earlier in any process.

---

[1] See efforts by the International Codes Council (ICC) to automate compliance checking, beginning with automated Energy Code Compliance checking, with Electrical Code, Plumbing Code and other compliances in the plans.

Can’t Build to Design

Building Controls don’t work because they were never designed. That was the recurring theme, both in and out of sessions, for Tuesday at BuilConn. Speaker after speaker repeated this, both on and off the podium.

Alan Edgar, of the executive board of NBIMS, came to BuilConn yesterday. He attended the Buildings 2.0 sessions in the morning, and was very interested; I did not, as I was talking to an “Experiences with Web Services” session. He seemed to enjoy it, and though it needed to be a perspective in NBIMS. The complement, of course, is that currently, controls are not.

I have long relied on a prop to explain the problems of control systems design. At any moment on the UNC campus, there are numerous capital projects under way. On any day, I can walk into the construction plan room and pull out one of the current plans. I turn to the Mechanical controls page – the one with three panes on it. There is one sheet for each floor, and the three panes are (1) a tag list for the controls, (2) a schematic for the controls and (3) a sequence of operations for the controls.

This is a reliable prop, because, I have never yet had to go to a second building. Flipping through the floors, it become obvious, even to cursory inspection, that these are not right. The tag lists will prove to have been developed for the 4^th floor and cut and paste onto the others, even onto the radically different first floor and lobby. Perhaps the Sequence of Operations will describe some system that is clearly not the one in the schematic. There is always some gross error – I have never had to go to a second building.

But perhaps the University of North Carolina is uniquely cursed? Last night, I talked

In conversation with an engineer who was doing a retro-commissioning project at another university. After collecting data on 47 buildings, he began trying to understand the pattern to the building’s consistent bad performance. The common thread? Not one of them had more than a partial design.

There is no excuse for this. A system design for a control system should modeled up front as part of the design, The schematic, the SOO, and the tag list should be 3 views of the underlying model. If a “designed” system does not meet this low bar, that of internal consistency, one has to wonder if it was designed at all.

If we do not design the buildings we send out to be built, we will never get to the next bar of designing them well. If we do not design them well, then LEEDS, Green Buildings, and Zero Carbon Facilities are a sham. If they are a sham, the design profession has been overcharging a lot of people.

Consider that the next time you walk into a “Green” building.