Articles » Building Information Models and Model Views


Building Information Models and Model Views

By Richard See, Managing Director, Digital Alchemy

IN THE LAST FEW YEARS, we have seen a great deal of marketing and press about Building Information Modeling (BIM). By now, most people in the industry must have a vague understanding of what BIM is, but may find some additional background, some specific examples, and more detail about how BIMs will improve quality, reduce costs, and enable new business processes should be of interest to most.

This is the first in a two-part article that will provide background about the evolution of building modeling concepts and systems, why product neutral BIMs are important, and how such BIMs will enable intelligent data sharing and enable the AECO industries to realize the kinds of efficiencies and quality improvements enjoyed by manufacturing industries today. Part 1 of this article provides background on building modeling, the larger context of product models, and initiatives to define a global standard for BIMs. Part 2 of this article will introduce the notion of Model Views, which are much like database views, how these views are defined, and how they will ensure predictable interoperability experience when used for exchange of BIM data between applications.


The notion of building modeling is not new. As early at the mid 1970’s the UK government funded research in this area that ultimately led to early building modeling systems including BDS (Building Design System) and RUCAPS which were used by early adopters in the UK and U.S. through the mid 1980s. Even these first generation building modeling systems included some of the concepts central to today’s BIM authoring software. Concepts including parametric element definition, building element libraries, multiple representations (graphic and analytic), and drawings as view or graphic reports generated from an integrated building model.

RUCAPS was replaced by a second generation building modeling system called SONATA in 1986 and saw much wider adoption, particularly in the UK, although it was limited by the fact that it required a workstation computer when other drafting oriented CAD systems would run on personal computers. However, in this same timeframe, a PC based building model system, ArchiCAD, was maturing and beginning to build a user based that continues today.

In parallel, the GLIDE (Graphical Language for Interactive Design), GLIDE-II, and CAEADS (Computer Aided Engineering and Architectural Design System) systems were developed by the CAD-Graphics Laboratory at Carnegie-Mellon University. Although not released as commercial products, they introduced more advanced solid modeling geometry for use in designing buildings and integrated database techniques to support more sophisticated models and extending the association of data with geometric representations1. These techniques were later adopted or emulated in commercial products.

These early systems were generally developed by people in the building industry that had a vision of using the computer to prototype buildings as assemblies of building elements rather than using the computer to create the same design drawings that had been used to describe buildings for centuries.


Throughout the 1980s, similar modeling initiatives emerged in various manufacturing and more specialized construction industries. Common interests and needs in these groups and projects eventually led to the formalization of the concept of Product Information Models and development of STEP (the Standard for the Exchange of Product Model Data) and ISO standard 10303.2 STEP has vigorously supported and widely adopted in the automotive, aerospace, process plant, and ship building industries, where the benefits of Product Information Modeling (improved information sharing, efficiency, and quality) have been widely observed and reported in the past decade.

One perspective is that the concept of Product Information Models, as introduced by STEP, formalized, harmonized, and standardized of concepts developed in many of the earlier projects and products (some of which are cited above). A Product Information Model can be thought of as a database of the product to be manufactured. That database can include a wide array of information about the product, including geometry, material, manufacturing and assembly techniques, tolerances, costs, and even information to support supply chain management, or it may include only some of these. The significant improvement of Product Information Models (and the pioneering products mentioned above) over previous product representations is that they are integrated information sets, which means data is referenced rather than repeated. This elimination of redundancy and reuse of data can/should lead to improved consistency, accuracy, efficiency, and quality—all of which lead to better products and productivity.


Building Information Models or BIMs should be thought of as the building industry’s application of Product Information Modeling concepts where the product is a building.

Early implementations of BIM have been very “geometry centric”, but this is beginning to expand now to inclusion of properties for use in analysis applications like energy use simulation, quantity takeoff, cost estimating, construction planning and various types of engineering analysis.

As with Product Models, a BIM can be thought of as a database of the building project. The information in this database will someday span the full range of data we now manage for building projects, but as an integrated data set. As such, BIMs are multi-representational, multi-dimensional, and integrate the information created by many industry domains.

Figure 2 is a simple example of BIM objects, properties, and relationships.3

BIM Models contain many types of objects. The most commonly understood are object representing the physical elements of the building. Our small example includes:

◊ Wall;
◊ Door;
◊ Window;
◊ Column;
◊ Beam; and
◊ Floor slab.

But BIM models also include many other object types that define abstract concepts and relationships like: relationships (for example connection and adjacency), object type definition (for example wall type and door type), hierarchies (for example containment), grouping (for example zones and systems).

2D geometry
2D Plan drawings are generated as geometric views or reports of the “plan” shape representations of the objects in the model. It is important to note that the “plan” representation uses industry standard symbolic graphics (e.g. door swing) whereas the “3D” representation uses 3D physical geometry. The image on page 20 shows two separate representations of a single object.

3D geometry
3D views are generated as geometric views of the “3D” shape representation.

Properties are attached to BIM objects to identify or describe them in some way. The range of possibilities for these properties is as wide as all the contexts in which they will be considered in a project, from design through construction and operation. Typically such properties are initially defined in a BIM authoring applications and can then be used by analysis and simulation applications to assess design performance (for example, thermal, structural, and quantity/cost).

Capture and management of relationships is a key area in which BIMs improve upon processes and software tools used in the past because they enable a higher level of model analysis than properties only. For example, adjacency and connection relationships between spaces are what enable automated egress checking in a building model.

Our example includes all of the following relationships (See Figure 3)

◊ Connection;
◊ Voids (an opening in the wall); and
◊ Supports.

Not Visible
◊ Bounds (walls, floor bound space);
◊ Contains (Project>Building>Story>bldg elements and space); and
◊ Connects (space to door, window, and adjacent spaces).


Standardization is a logical step in the evolution and adoption of new technologies and processes as it can and should enable a next level of efficiency and adoption to industry.

Standardization for BIM logically followed the path taken for standardization of Product Information Models in STEP. This began in 1994, when a then fledgling AEC team (including the author) at CAD began development of a standard library of building model elements as the basis for interoperability between AEC add-ons to CAD. Success in the initial prototyping eventually led to the formation of the Industry Alliance for Interoperability (IAI), which included 12 industry leading companies, led by CAD, that developed the original Industry Foundation Classes (IFC). IFC was introduced as the “common language for interoperability in the building industry” at the 1995 AEC Systems conference in Atlanta. All 12 companies demonstrated