MVD Process
The life-cycle of a building is characterized by a large number of participants that all play vital roles during some portion of it. Many of these participants develop information and results that they need to share for use by other participants later in the project. Traditionally these information exchanges were accomplished by paper document exchanges. In the buildingSMART process the results are incorporated in the BIM (Building Information Model) and communicated downstream through the interoperability of IFC among the software tools that are used by the participants.

Exchange requirement (ER)
When an architectural firm is designing a building (Process C), for example, it receives information from process A, B and D. If in the design process it uses one of the IFC-compatible computer design tools, then the results can be incorporated in the IFC-BIM to be passed on to structural engineers (process E), cost estimators (Process F) and others. If the downstream receivers of the IFC-BIM are also using software tools that are IFC-compatible, then they are able to read the necessary information directly from the BIM to perform their work.
Contracted information exchange
These exchanges should be thought of as a “contracted exchange” since the downstream participants depend on specific information provided and incorporated in the IFC-BIM by upstream participants. The information required to perform their work will typically be only a subset of the information in the IFC-BIM.
The IFC data model is comprehensive and flexible and can support a wide range of data to be transferred, but since the downstream participants expect very specific information each of the data exchanges should be carefully specified to ensure that required information is proved sufficient and complete, including for example naming and classification.
How IDM and MVD work together

Overview: Before AEC+FM professionals can perform data exchanges the vendors of their favorite software have to implement IFC interoperability - the vendors have to enable their software to read and write IFC format. For repeatability and reliability <!--[if !vml]--><!--[endif]-->, this interchangeability should support “contracted exchanges”, i.e. information exchanges that serve a particular transfer. Information Delivery Manual (IDM) defines the users’ “contracted exchanges” and Model View Definitions (MVD) defines the implementations in software. IDM and MVD are further detailed below. Once implemented in software, any software should be fully capable of exchanging the required information for the specific process-to-process scenario. While the software “should” be capable of doing it, the certification (by buildingSMART) of the software ensures that they actually meet the requirement as specified in the MVD. Finally, the software is tested by users to ensure that the users’ original business requirements are fully met by the software capability.
Information Delivery Manual (IDM)
The IDM (Information Delivery Manual) defines in the language and perspective of the professional participant what information must be contained in the “contracted exchange”. The term “IDM” is also refers to the process of developing and documenting the user requirements which may be part of a buildingSMART Aquarium, or as a user group activity.
IDM also identifies the applicable business rules governing the subject exchange. For example, it may require the user applies specific classification system, such as Omniclass or constraints on the acceptable range of a parameter.
The combination of exchanged requirements and applicable business rules results in the formal description known as the Exchange Requirements Model (ERM). Up to this point the requirements are in the user world and not linked to a specific computer solution. I.e. the requirements could be satisfied in any applicable format.
Model View Definitions (MVD)
In the MVD process the ERM is mapped to IFC-specific “Concepts”, i.e. how the exchange of the required data element and constraints can be accomplished using IFC. The MVD is a software specialist’s way of looking at the user requirements for a specific business process, documented in a way that enables the implementation of the exchange capability in software. The MVD tells the software implementer which IFC elements to use, as well as specifics of how the implementation should function. The latter is necessary to ensure all software implementing a specific MVD will behave in the required way. For example an application may be required to support ‘classification’.
Attachment
| Attachment | Size |
|---|---|
| Document for download | 1.33 MB |

