Model View Definition (MVD) - An Introduction
What is an MVD?
In general, a MVD, or "Model View Definition", is a subset of the overall IFC schema to describe a data exchange for a specific use or workflow. MVDs can be as broad as nearly the entire schema (e.g. for archiving a project) or as specific as a couple object types and associated data (e.g. for pricing a curtain wall system). The documentation of a MVD allows the exchange to be repeated, providing consistency and predictability across a variety of projects and software platforms.
To support BIM interoperability across hundreds of software applications, industry domains, and regions worldwide, the IFC schema is designed to accommodate many different configurations and levels of detail. For example, a wall can be represented:
- as a line (or curve) segment between two points;
- as one of many types of 3D geometry for visualization and analysis (such as extruded solids or triangulated surfaces);
- as simple forms or with specific construction detail (capturing individual studs, pipe fittings, wiring, etc.)...
...along with data such as engineering properties, responsible party, scheduling, and cost information. But not every domain expert in the design, procurement, fabrication, and operations processes of a project need all the same information delivered or received. A MVD will narrow that broad scope depending on the need of the receiver of the information for a specified workflow.
Since IFC is a vendor-neutral, or vendor-agnostic, schema, MVDs are data-centric rather than application-centric. This means that the workflow and end user information exchange requirements determine the extents and form of the model view, not specific software capabilities, or limits, of any multitude of applications available on the market. However, the specifics of a MVD may be influenced by more general software capabilities or needs, depending on the workflow.
An architect is sending a simple model to the client to place within a larger urban context model, allowing the client to visualize the design, the architect doesn't need to send all the complex modeling operations data (e.g. CSG) and object attributes, but can send a simple surface-based geometry model with simple color or texture mapping.
At the same time, the architect might send the contractor an IFC file that has only a locator, or placement, for windows and all their identification and performance specifications, because the contractor's application doesn't display geometry, just a report for costing and procurement.
In each case, the architect doesn't have to delete any data before sending it, they just specify which data gets sent from their application to the client for optimal use in a different application.
How are MVDs used?
The stakeholders in a project (architects, structural engineers, building systems engineers, facility managers, etc.) have different responsibilities, expertise, and needs in creating and using building data. Ultimately, they must share that information between the other members of the project team to accomplish different tasks. Thus, there's a need to clarify which subset of all the data, and its format, is needed to exchange for a particular use. Such subsets of data can be defined by parsing the overall IFC schema into smaller "model views", where the end user requirements of needed information are specified. Project delivery contracts may reference exchange specifications to require data to be delivered between parties. A MVD will describe which objects, representations, relationships, concepts, and attributes are needed for the receiving stakeholder and their software application to accomplish a desired task.
Examples of MVDs include:
- Architectural Design to Structural Design - where the architect is providing the structural engineer a model "background" that can be referenced for the placement and design of structural elements.
- Architectural Design to Quantity Takeoff - where the architect is providing the general contractor a model that has accurate element placement extents for extracting quantities and assigning cost figures.
- Building Envelope Design to Energy Analysis - where an architect or building envelope designer/engineer provides the energy consultant a model with specific construction types and material thermal values, as well as thermal comfort values for internal spaces to determine building performance.
- Construction Operations Building Information Exchange (COBie) - where a contractor provides as-built data to the owner and facility manager for operations.
While MVDs may be used to require particular data to be included, they cannot alone guarantee that data is correct or consistent. Data exported by applications may be validated to conform with an exchange using other BIM tools and services.
Who supports MVDs?
All software applications that support the export of BIM data via IFC have some kind of MVD support. Typically, a BIM-authoring tool will have a list of MVD options in their IFC export user interfaces. Depending on the type of BIM tool, the MVD support will differ because of the domain the application serves, such as space planning, architectural, structural, or building system MVDs.
By developing and supporting implementation of a MVD, stakeholders are standardizing the flow of information, so these exchanges can occur without reiterative discussions on what and how information is exchange, each time it is needed. Information exchanges can then happen more frequently and consistently, with little intervention.
Future of MVDs
MVDs need specific implementations by software vendors. Therefore the concept of MVDs will change. IFC5 will be modular with a shared base. The definition of exchange requirements will be done using Information Delivery Specifications (IDS). More on this on the Technical Roadmap page.