I frequently hear that the IFC schema is too limited. Well, no doubt, it does have its limits.
However, quite often it is the critics’ superficial knowledge of IFC what is the limiting factor here. Sorry to say that. And both ends are responsible for this situation. IFC is indeed complex (because life in general and construction in particular are); and people in our industry tend to believe what is promoted by big software companies (which in return are responsible for many limitations). Anyway, we are here to change things for the better.
So what do you do when you really reach the limits of IFC? When data structure, data types, file sizes etc. no longer permit working with this format (exclusively)?
Welcome to the world of external references (again!). We already had a quick dive into external documents, and that was just a particular case of what we are about to discuss now.
I recently had a meeting where the usage of IoT BIM objects were discussed. There is a standardized format called bacnet that defines how smart devices communicate with each other. How would we store this kind of data in IFC? Psets? Not at all? Ditch BIM for this use case?
Fortunately the IFC documentation helps here (a bit hidden, though). A bacnet address is (simply) another classification. It’s an entry in a externally defined system, just like an IP address. It is structured in a hierarchical way and has a well defined nomenclature.
So this classification is the key (pun intended) to find the device of interest within the bacnet system. This means not all the live data has to go into the IFC model itself. If necessary one can easily switch from one system to the other or join both data sources in one dashboard or report.