NBIMS and Enterprise Interfaces

The National Building Information Model Standard (NBIMS), part of the buildingSmart effort, is critical to solving the biggest issues that face the Building Design / Construction / Operation industries. NBIMS defines a single life-cycle data model for any building that can be used by all process. Each process then can bring its results back into the original data model. For example, a building Energy Model can be generated directly from the design and the outcome of that model re-incorporated directly back into the model. The energy model, along with all other design and construction information is available throughout the operation of the building.

NBIMS suffers from a three handicaps. It sometimes matches the fractured industry it addresses by being as fractured itself. It does not recognize its capability to do more than improve the game, but to change the game, by not providing the new players it attracts any sort of roadmap as to how to get on the field. The details of capital asset and acquisition are never going to be good dinner table fodder. Even so, it is important to understand what NBIMS brings to the design and operation of building systems.

I am not a domain expert on concrete. I am an OK coder. What I have done throughout my career is integrate the un-integrate-able. And that draws me to surfaces, to boundaries, and to their definitions – to what has just started to be called, in IT, Architectures. Architecture maximizes competition by providing a known clean cleavage point between systems allowing swapping of components. A good architecture enables this swapping without recasting either side while allowing immense diversity of performance and approach within each function. And a Good IT Architect has to figure out how to get there while getting value from each step along the way.

By focusing on the Service aspects of the BIM, and of the interfaces, I am not only meeting my day-job requirements of focusing more on operation than construction, but striving to find quick wins to drive acceptance further into the market.

In the mechanical world, I need to understand the interface more than I need to understand the inner workings of a component. If I swap one sensor for another, it is necessary that it use the same electrical signals, and produces the desired level of accuracy – not that it use the same inner technology to measure what it measures.

If I want to swap out a motor for a more efficient one, the key interests are can I signal that motor to start and stop, and can it produce sufficient force. I may, in different circumstances, care about other features, such as desired vibration targets, or appropriate predicted longevity. But those are external to the interface.

A couple months ago, we had a joint conference call between oBIX and NBIMS. Much of it was quite interesting, and the opportunities for each project to burnish are great. Afterwards, several oBIX members expressed to me frustration that the NBIMS people seemed to want them to learn too many details and could not tell us how to interact. In particular, a focus on the detailed specification of concrete aggregate arose. Why did NBIMS want us to know this?

I would shake my head (ineffective, since I was on the phone) and think to myself – “And yet, you (the controls industry) want me to learn all your points and tags to interact with building systems…

I do not want your details. I do not want to learn BACnet or LON or KNX or Metasys or any of a hundred proprietary protocols so I can spend my day re-writing building systems. That why I hired mechanical engineers.

I want higher level abstractions. I want surfaces that sound like business services. I do not want to learn concrete. I do not want to learn about your HVAC system. I do not want to learn about your access control system. I want to use higher level abstractions.

I just want it to work, and do what I tell it to do. That is what an enterprise interface is for.

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.

Software Factories and Building Systems

Despite all the software written in the last 50 years, the software backlog is growing. Just about everything we buy today has embedded software, and integrating that software requires more software. Software factories are a set of concepts and approaches to the growing backlog of software.

Many developers disdain any structured implementation as is required to support software factories. Too much software is still written by some variant of the lone programmer, coding everything from scratch, and scorning, often angrily, any layered architecture as inefficient. I spoke to a class on Friday at Case Western Reserve, on building interfaces and GridWise, and one of the first call outs from the crowd was on efficiency.

Maximum software efficiency matters in a few places. I want device drivers to be fast. I want database hash tables to be blindingly fast. I want network protocol stacks to be fast; I also want them to have a layered interface so I can swap them out. On my first commercial contract, I was obsessing on an efficiency issue. I was using every technique taught in the Computer Science Department of UNC. A senior programmer pulled me aside and pointed out that if the program stayed in place, unchanged, for 10 years, it would cost the data entry pool a total of between 13 and 15 minutes in additional entry time during that period. He suggested that as I was currently ready to start my 3^rd day of tuning, my efforts might be inappropriate…

Keith Short has compared software development efforts to food preparation. When you go to a good restaurant, you choose the meal from the menu. The chef has designed the menu, chosen the ingredients, designed the processes, and purchased the equipment used to prepare the meal. The line cooks prepare the meal you chose from the menu as requested on your order. They may modify the standard menu item on the menu in standard variations (“Medium rare”), or to meet special dietary considerations, or even prepare a meal not on the menu.

Developing software without development tools is like going to someone’s house for dinner. The cook may never have made the dish before. A whole array of spices that may never be used again might be bought for this meal. Prep work is far from efficient. The experienced host has plenty of wine, ready to serve just in case the dinner comes out an hour late. Last minute special requests are difficult to honor; the whole party will usually eat the same thing. While the company and occasionally the food might make the evening memorable, the result rarely competes on effort, or true cost, or on predictability of result, with a meal from that good restaurant.

Keith Short has written about software factories on his site ( http://softwarefactories.com ):

A software factory is a product line that configures extensible development tools…with packaged content and guidance, carefully designed for building specific kinds of applications. A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment:

By analogy, the architect sets up the software factory by performing the roles named above for the chef. The well designed kitchen is the development environment; the processes are the food line. The schema is the menu and the recipes are the software templates. The developers, then, have the role of the line cooks, following recipes, making minor adjustments to defined practices, and adding a few custom requests.

This approach sounds tailor-made for the problems of embedded building systems. These systems can be described as fitting a limited number of functional categories. Albeit with different sensors and controls in each instance, and different spaces and people supported in each installation. Each system should be properly factored systems and expose a standards-based interface. We can expose building systems as a family of applications defined around a common set of WSDL/EBXML. We can define the Web Service patterns we want to use, as well as configurations and the security policies we would like applied.

Software factories are more than just a strategy for modeling tools and Domain Specific Languages (DSLs); they are a way to think about software development using pre-defined content. They respond to the problems of rising technological complexity and expectations of users.

Do any of my readers have experience using software factories in this domain?

Other People’s Money and Poor Decisions

I always read the local paper when I am travelling. I may rely on the national papers for consistent use, but they cannot give you the flavor of the local town. I always get a fresh perspective on something from the local paper.

While driving up to drop my daughter off at College, we stopped overnight in Wilmington, Delaware. One of the top stories was the local electric utility’s industrial policy. The town proposed to give reduced rates to new industry moving into the area for a period of years. The details were still being hashed out, and I may misunderstand them. There was some discussion as to how to determine who was eligible, i.e., how many employees, were they really “new industries, and so on.

This sort of meddling with markets is wrong in nearly every way. It encourages continued poor decision making by companies. It is deceptive to the citizens while setting them up for disappointment. It leads to a misallocation of power within the market.

The company that takes up this offer is relying on subsidized energy costs to support processes that are not sustainable economically. It has decided not to re-engineer its work to acknowledge current and future energy costs. It has made this decision despite recognizing itself as unusually sensitive to energy costs to stay in business. When the subsidies end, the company will fail or move on to the next sucker. The local town council is paying them to continue to make bad decisions; corporate executives are accepting the bribe to meet short term revenue goals.

The true costs of this policy will remain unknown. City officials will never reveal information damaging to their self image as enlightened and beneficent. Local reporters lack the financial training to wade through the creative accounting that will cover up internal cross-subsidies and cost over-runs. The charge to each family, rich or poor, will never be itemized. The largest beneficiary will be the corporate officer, far away from the community.

This sets up a direct dollar transfer from efficient users of energy to the inefficient. Long term local industry will not get these rates to stay in the community. Homes will cut back or conserve to pay the inflated bills of the most inefficient industries. Local programs to encourage upgrades and insulation will be cut back. The community ends up with an economy bases around inefficient companies poorly positioned for the future.

Only economically unaware, who have been given control of other people’s money make decisions this bad. No one would ever make this decision with money pulled from his own wallet. When public officials decide to design policies to limit transparency in decision making, the public always loses. The public always does when systems are established primarily so that the decision makers never have to tell the funding citizens any numbers.

And the nation loses because Wilmington is paying companies to use more energy.