IFC, MVD, IDS – What’s it all about?
So I’ve been trying to understand IFC for a while and the further I go it seems like a never ending rabbit hole. As part of the information management process, understanding the terms like IFC, MVD or IDS is quite important especially when we talk about structured information exchange.
IFC – Industry Foundation Classes
Let’s start with some basics. IFC is a schema and is described in the ISO 16739 standard. This standard defines something very important – logical data structure (schema). Files conforming to this schema must be formatted and delivered utilising ISO 10303 Standard for the Exchange of Product model data (STEP). STEP has many parts. One of those parts (ISO 10303 Part 21) is well known – STEP Physical File Format (SPFF). It is normally used to exchange design information. The other one, ISO 10303 Part 28, defines the XML format to exchange IFC data. There are basically a few different file formats as well as alternative ones as far as they map to underlying IFC schema (i.e. spreadsheet).
MVD – Model View Definition
The other important part of the IFC standard is Model View Definitions (MVD). As you can imagine the IFC schema is like a dictionary describing every possible object found in the built environment:
There is no discipline in the world that would require all this information all at once. Therefore, Model View Definitions take a portion of the IFC data and use it to exchange information from one system to the other. Some of those definitions overlap in the data that they exchange, but they all serve a specific purpose. An image below shows this relationship:
The purpose of MVD was to ensure that specific data or geometry is transferred between software applications in standard manner, allowing for automated validation etc.
All of the above sounds like a solid concept. However, there is a slight issue with this approach which has been recognised by buildingSMART. When it comes to software implementation, in theory each MVD should be certified. This would be fine if we had a couple of MVD’s, but that’s not the case (MVD Database – buildingSMART Technical). Even if software vendors wanted to get certified, the cost alone outweighs the benefits and prevents smaller vendors to be included in this activity.
Another issue is that to exchange information we need all used software utilising the data to import and export specific MVD, which again seems improbable given the number of software we use in construction projects.
On top of that, we know from practice that when it comes to projects, we have bespoke client requirements that do not conform to specific MVD’s, thus we end up creating what could be coined as microMVD’s that are project specific (btw, for a bit more technical people – there is a legacy tool (archived) that was used to create MVD’s – ifcDoc. Note: today, specific client requirements are usually captured in excel spreadsheets and sometimes in databases, which vary in their quality). Obviously, those microMVD’s wouldn’t be certified, thus we end up using all sorts of software to export, import, validate, merge required information exchanges.
The above examples clearly outline why we need a better approach.
IDS – Information Delivery Specification
MVD’s are dead. Long live IDS!
As buildingSMART describes it:
‘An Information Delivery Specification is a computer interpretable document that defines the Exchange Requirements. This can be a combination of IFC, Domain Extensions, and additional classifications and properties (either stored in bSDD or somewhere else). This is the standard to use to define your Level of Information Needs. It brings validation of IFC to the client, the modeler and the Software Tools that perform (automated) analyses. It holds the ability to create localized and use-case specific requirements for your project. The IDS is the missing link for predictable and reliable data exchange workflows.’
You can read more about it here: Technical Roadmap 2020 – buildingSMART International
IDS standard presents a great improvement on the information management process and I think it aligns fantastically to ISO 19650 series as well as Level of Information Need. The best part is that it should be imposed by the client, verified by software, validated by the user and finally validated again by the client. Here’s a great diagram from buildingSMART outlining the concept:
What impact does it have on information management?
Well, instead of relying on spreadsheet requirements, imagine that you get a machine-readable IDS from a client. You will be able to import those requirements into your software and export compliant information exchange. Rather than sending your IFC-SPFF’s to a third party to validate the information exchange you will be able to use automated software to check your data compliance – this is a dream!
I bet we will face other challenges, such as adoption rate between clients, consultants and software vendors, but I think it’s a major step in the right direction.
Can you use IDS today?
Yes and no. It’s still in development, but it seems to be developing faster than other buildingSMART projects. Technical information is here: buildingSMART/IDS: Machine readable standard to define Information Delivery Specifications (github.com)
There are already a few products in development such as IDS Creator (artomczak.pythonanywhere.com) and www.xbim.it and others.