The Case for oBIX in Laboratory systems

Well, if not oBIX, something like it.

Most data in modern research is collected by automated systems. Computers assess, quantify, and print out data. Some may be able to produce spreadsheets. Some produce graphs. (I remember measuring graphs with great care to turn them back into numbers in a previous career). Some may extrude CSV (comma separated values) files, to be imported into databases. But almost everything starts with machine measure and tabulation.

Often the information you need to understand the experiment has been recorded, but it is only available in a nearby system that the researcher either has no access to, or does not know he can get.

The biologist who recently asked for access to our operations data is one example. He works with plants in greenhouses. Greenhouses strive for, but do not always produce, specialized conditions. Understanding plants, and small differences in growing plants, often involves understanding the conditions they grew in precisely. We have a system that tracks minute by minute the temperature and humidity of the areas it monitors. In areas in which natural lighting is being used and augmented, light levels are also tracked. This researcher asked for access to the minute by minute temperature, humidity, and light for each zone in the greenhouses. What is wonderful about this request is that we can provide it essentially for free

There other systems, specialized systems that researchers work around. Back when I worked in a Biochemistry lab, we had large variances in the reactivity of the materials we worked in. After half a year, I guessed that these problems were caused by variances in the level of liquid hydrogen in the large carboys we stored samples in. Today, those carboys are replaced by ultralow freezers. While I never could prove this, I got outstanding results by working straight through (a 50 hour shift every other week) and thus eliminating variability. You can find the results on the web if you are interested in quassinoids.

There is a large cancer research center on campus. As part of the background for each grant that it submits, it includes general material on the quality of the facilities and how they enhance the research performed therein. One of the pillars of quality is an ultralow freezer tracking system.

This system monitors all the laboratory freezers in the building. Data on the quality of the freezer systems is carefully monitored. Each freezer has its tolerance, and it can be documented that each system stays within its tolerance. This documentation is part of the overall facilities quality report. If your sample is stored here, it will not be accidentally thawed out.

What is not available is any easy way for researchers to access the same information. If they ask the right person, they can get a spreadsheet describing the details of the performance of a particular freezer. They can request these periodically. This system, like most building monitoring systems, has no way to let researchers pull direct feeds of data from the freezer monitoring system. There is no way for one of several researchers using the same freezer to set personal alarms on conditions that matter to him. Most of the researchers are unaware that they can ask for anything.

Every automated laboratory system produces its own special data format. There is an effort underway, UnitsML, that hopes to establish a data standard for every measurable physical condition. All testing runs, all data, will be able to be delivered in a standard UnitsML format.

When the researcher can freely get to information on conditions whether from Laboratory equipment, from specialized laboratory infrastructure, and from buildings in self describing formats over the internet, then better analysis is possible. When students can use this information as well, without too many people interfering with experimental conditions, than education is improved.

I could go on…but the motto of out Building System integrator seems appropriate here. “No Data Left Behind!” These words are good for research as well as for building operations.

Getting Past the Alligators

"Don't solve problems, pursue opportunities.” — Peter Drucker

There are lots of problems associated with bringing transparency to building operations. The EBMS project (see archives for details) I am working on offers me new problems every day. Today a friend and co-worker reminded me to think of why we started this project, and what the real value is.

The EBMS project has to provide a central vendor agnostic means to monitor and operate the energy using systems across the campus. It shows every promise of doing so, despite repeated problems of security, and definition, and great fear from line managers that no one has ever done it before. Of even more concern to many is that it brings transparency to operations that have always been, to the building inhabitant: invisible and unknowable. What if the building tenants want to interact with how things are done?

There are similarities with the oBIX committee. I came to the oBIX committee having spent several years writing, and speaking on the benefits of allowing access to building operating information, of extracting more value from each system, of transforming and expanding the resources available for pedagogy and research. The oBIX committee, alas, is about who shows up from which company. Companies may participate to open new opportunity or, more frequently, to watch for new competition. Everything takes too long and free speaking offends those who have market positions to defend.

As Ronald Reagan said (in the only clean version of a much older quote), “When you are up to you armpits in alligators, it is difficult to remember that your initial objective was to drain the swamp." Today, while talking with this friend, I was reminded why we ventured into this swamp, and why it is important to wrestle or slay these alligators.

Single purpose data is one of the most expensive resources of any organization. Single purpose data is comforting to the current politics of any organization. Single purpose data cannot be used for any reason other than what it was designed for. Single purpose data only rarely rises to the level of information. Information that is horded and isolated never becomes knowledge.

Knowledge is power, they say. When share information, you change the power relationships in any organization. Technology is hard, design requires work, but changing the power relationships, that is politics, and politics releases the largest and hungriest alligators.

We had a vision without alligators. We had a vision that maximized the University’s return on investment by maximizing the value received. Sensors cost what they cost. The low voltage systems that string them together cost what they cost. The value, however, the value is in how many ways you can use the information. Opening the doors to information opens up the organization to new sources of value. If you can expand value while maintaining a fixed cost, you come out ahead.

Recently we have caught glimpses of this. A professor in Biology requested the availability of our operations data, i.e., minute by minute temperature, light, and humidity, for experimenters in the new greenhouses. The Archeology department wants ready access to all information on managing their archives. The Geology department can let students pull live data from the outside air sensors in hundreds of buildings to better understand microclimates across campus. Information pulled from mapping, from building operations, and from the chilled water loop can help engineers understand big picture issues abstracted away from the mechanical details.

And that is just in mechanical systems. Later this week I will write on the opportunities in exposing laboratory systems to open interfaces. At the end of it all, we started this work to expand value.

It’s just that the alligators are so large, they get all our attention.

Sloppy Wet in Carolina

It’s been raining for days, a beautiful finish to a long dry spell in the Carolina’s. Durham was down to 60 days of water, and so was considering restricting lawn watering. The homeowners associations in town were warning members to keep their yards up. Even three days of on-to-two inches a day won’t make up for a long drought. Today, at last, it stopped soaking into the parched ground and began running off.

On the other side, all the fall flowers that were not blooming because of the drought rushed to get a full season’s reproduction in. I woke up with puffy eyes and a swollen throat—I certainly didn’t feel like writing.

Flowers weren’t the only thing that was behind. Eight months of drought meant the gutters had not been rinsed out once. So today they were clogged up. The water sucking into the ground left the well murky.

But I don’t care. It’s wet again. The sound of water on the roof was odd, at first, something unremembered. But it came back. And with it came sound sleep. Even the dogs were quieter. The deer who have been coming out of the woods searching for watered shrubs stayed at home. That nagging worry about whether the well would make is relieved. I slept well.

And I plan to do it again.

IT is the One Department that Can’t Afford to Miss This Boat.

A recent poster commented that IT Departments word be serious opponents to enterprise enabled building systems>

The IT groups have the least to gain and will be asked to support additional risk. Without a high level sponsor for the project, the chances of success are minimal. Even with high level support the IT department wields a lot power, they throw around support issues, delays in core responsibilities, risk and fear.

I think this is partially true.

A report that came out this week reported that Servers, PCs and network gear us 9.4% of the entire energy load of the US. A conservative estimate is that data centers use 45 billion kilowatt hours per year. I suspect that number is low because cooling is often on a different budget than the data center.

The poster continued that corporations only want to be “Green” only if it doesn’t cost appreciably more than the status quo. With $80-a-barrel oil, we will find that many data centers will soon scramble to explain their new costs. Many a data center manager will find that the cost of not integrating building systems into data center operations is larger than integrating them.

oBIX, and even BACnet Web Services, reduce the cost of integration. Certainly, there some IT shops who still do not have an architecture. Many who claim to will say something nonsensical like [database vendor] is our architecture. If we set the bar higher than that, the better IT shops are moving to some sort of Service Oriented Architecture (SOA), often based upon web services. (I must admit, though, that many are become disillusioned with SOA. These are often the ones who “bought” SOA as a product without adapting their IT business processes.) Those IT shops that have developed some experience with SOA, that is, the better IT shops, will not see as much risk.

I have worked with a data center whose first request was “Can you take all that web services and change it to SNMP.” They were definitely risk-adverse, with change being the risk they feared most. They certainly did not want to be anyone’s whipping boy, again, certainly not for embracing something new like SOA. Still, they were asking the right questions. They lived by their old fashioned network service monitor. It ran on old fashioned SNMP. By demanding that the building interfaces communicate with them in their language, they were actually embracing SOA. Shhhh – don’t tell their management.

Some of the best companies are already integrating building system operations with the enterprise. They do it with great expense, and great effort. These companies have so many facilities, and such large demands, that they cannot turn a blind eye toward them. Each site, each store that they interact with requires a custom integration. These are the companies that will leap first upon the tools for simpler integration.

IT groups fear additional responsibility for systems that are complex and outside their expertise. The disciplines and techniques of building systems are outside their experience. Inappropriate integrations may put at risk both the IT shops current responsibilities and the performance of the building systems.

The answer, then, is to not do inappropriate integrations. Let the building system be a building system. Leave the contractor or engineer responsible for the internal operations of the building system. Integrate only with the external surface of the building system. Define the surface of the building system in terms of services.

Services concentrate, rather than dilute responsibility. Services hide their internal processes and thus reduce complexity. Services imply their own metrics for measurable performance, increasing accountability. Service definitions enhance interoperability, and thus reduce the risk of technology selection. The service, not the process is the right level of integration.

The IT is the only group that by speaking out early, can mandate the building systems expose only services. It is failure to do so that will increase their risk most.