In the previous chapter, IDM methodology was used to describe the breakdown of information exchange into small and manageable units known as exchange objects. The breaking down process uses a plain language because it allows for smooth communication between non-technical users. In this chapter the requirements will be connected in a technical language using MVD methodology.
6.1 What is MVD?
The IDM outputs from the previous chapter will help developers to understand the interoperability required by a user between BIM applications (BuildingSMART, 2012). With this data as a guideline, the developer will set the interoperability from a technical point of view by creating a Model View Definition (MVD) (BuildingSMART, 2012). Thus each of the exchange elements identified in the IDM stage will be translated into a readable language schema format (figure 6.1) such as IFC or STEP (Hietanen, 2006; BuildingSMART, 2012).
DEFINITION CONFIGURATION
IDM MVD
118
6.1.1 Goals for MVD
The main goal of MVD is to ensure that the data exchange will meet the requirements detailed by a user in the IDM and then he/she will know what results to expect from the export and import process (Eastman et al., 2011). Additionally, there is a series of requirements to achieve during the MVD process to reduce as much as possible the data ambiguity during the implementation process (BuildingSMART, 2012):
- Enable data exchanges. The MVD provides a structured method for refining and merging data exchange requirements into packages for software implementation. - MVD provides support for the IFC implementation through a well-established
method, avoiding falling into an iterative trying and error process. Using an MVD should be the easiest way of supporting IFC implementation in software.
- A certification process will allow industry practitioners to understand how the IFC- based data exchange works in providing data about the capabilities and the limitations that the based data exchange has created.
6.2 Developing MVDs
6.2.1. Requirement rationalisation
Before creating a MVD, there is a need to identify and to group those exchange requirements created during the IDM stage that have the same exchange objects. The idea behind this rationalisation process is to reduce the number of MVDs that need to be developed and to avoid any duplicity of data (Aram et al., 2010). Figure 6.2. summarises the outputs from use case 3 (see appendix A.3). The left column shows the exchange requirement (ER) while the right column groups the exchange objects required for each ER. A review of the ERs allows for the identification of identical exchange objects even if they belong to different ERs. For example, the ER highlighted in red (BIM model alternatives and approved design), and the ER highlighted in orange (obtaining energy data, energy matching results and indicators) contain the same parameters even if the information nuggets or values assigned to these parameters are different in various ERs.
119
Thus, there is no need to develop a MVD for each exchange object. Instead, it will be possible to identify equal data and reduce the number of MVDs to develop. In chapter 5, were identified 34 information exchanges and 183 exchange objects, however applying this rationalisation process makes it possible to reduce the information exchange to 18, while the exchange objects are reduced to 67, thus just 67 MVDs will need to be developed.
Figure 6.2 Summary of the outputs from the design check and energy matching in use case 3
120
6.3 MVD example
In the previous chapter was discussed the method of describing interoperability by using a non-technical language. In this section the outputs from the previous chapter will be translated into a technical language. This will be undertaken by using the MVD procedure explained above in this chapter.
As explained in the previous section, by using a rationalisation method it is possible to reduce the number of exchange objects from 183 to 67. In addition to this consideration, from each scenario will be selected three different exchange objects to develop the interoperability. By doing so it will be possible to reduce the number of objects to consider. However, the elements that are chosen will need to describe a different kind of information e.g. a solid element (beam, slab, wall and so on), document, cost, library objects, and information objects.
Below is illustrated and explained an MVD example. The remaining MVDs are presented in detail in Appendices B. 1 to B. 5.
- MVD # 01
The first exchange object to describe will be ´Lifecycle cost´ in the information exchange
Ke ite ia´ from the first scenario. Figure 6.3 shows the MVD for lifecycle cost. It is described through three entities:
- ResourceLevelRelationship is an abstract data entity to describe the relationship between resources and level entities.
- ExternalReferenceRelationship makes reference to the external database (libraries, documents) when the information source is not explicitly represented in the model. The lifecycle cost does not represent a particular element in the model and thus it will need to use ExternalReferenceRelationship.
- AppliedValue defines three sub-entities (AppliedValueSelected, Date and CostValue). These sub-entities are useful in defining an economic value, currency units, and date when it will become important for the project.
121
BuildingSMART suggests using CostValue to detail the amount of money in a situation such as annual rate return, bonus, contract, estimated cost, maintenance, material, overhead, profit, purchase, rental, repair, replacement, and whole life.
122