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.