Chapter 2 Discussion Questions
3.1 INTRODUCTION
The design and construction of a building is a team activity. Increasingly, each activity and each type of specialty is supported and augmented by its own com- puter applications. Beside the capability to support geometry and material lay- out, there are structural and energy analyses that rely on their own building representation. A schedule of the construction process is a nongeometrical representation of the project, closely aligned to the design; the fabrication models used for each subsystem (steel, concrete, piping, electrical) are other representations with specialized detailing, in addition to others. Interoperability is the ability to pass data between applications, and for multiple applications to jointly contribute to the work at hand. Interoperability, at the minimum, eliminates the need to manually copy data already generated in another appli- cation. Manual copying of partial project data greatly discourages iteration during design, as required for fi nding best solutions to complex issues, such as structural or energy design. It also leads to errors, where manual copying inev- itably leads to some level of inconsistency. It also is a great restriction to the automating of business practices. Suppose that all eBay and other e-business
ch003.indd 100
ch003.indd 100 3/8/11 6:09:09 PM3/8/11 6:09:09 PM
www.EngineeringBooksPdf.com
could only work without personal accounts, requiring you to enter your full profi le each time you used the site; tracking of your order would not be practi- cal. The e-commerce site could not bring you special offers. Interoperability opens up new paths of automation.
People are used to geometry exchanges between applications, using trans- lators such as DXF, IGES, or SAT. These are fairly robust; people can visually inspect the geometry for any errors and correct them. Why is building model exchange more diffi cult? The reality is that we have moved past the mod- eling of shapes and geometry to the modeling of objects—fi rst generic and abstract ones, and later objects corresponding to real products or that will be instructions for construction. While geometry has been the main concern for drafting and CAD systems, with BIM we are now representing multiple kinds of geometry and also relations, attributes, and properties for different behav- iors, as described in Chapter 2. The model, while integrated, must carry much more information than do CAD fi les. This is a large change and the support- ing information technology methods and standards for achieving this are only incrementally being put in place.
In the last chapter, we distinguished three types of BIM applications, as tools, as platforms, and as environments. Interoperability supports different capabilities and addresses different problems in exchanges of data across these three levels. The most common and important form of data exchanges are between a BIM platform and a set of tools it can support (most common are analysis tools, such as structural or thermal analysis, or quantity takeoff, scheduling, and procurement applications). In these cases, specifi c portions of the platform’s native data model (the data structure that the platform uses internally) are translated. The translation is realized by defi ning the needed model data on the platform (called a model view) and putting that data into the format needed by the tool and fi lling in other nonmodel information. Usually, the translation from platform to tool is one way, as the receiving tool lacks the design data or rules required to correctly update the platform’s native building model. The BIM tool’s results inform the platform user, and the user updates the original model. In a few cases the tool’s results can be used to generate automated design changes in the platform, such as in searching through an automatically generated set of designs for those which are closest to some goal, or eliminating an error, such as automatic rerouting of mechanical equipment in response to clash detection. These types of automated changes based on a review, are likely to increase. Platform-to-tool exchange is the most funda- mental form of interoperability and is supported by both direct application- to-application exchange and also through shared neutral exchange formats, such as IFC.
ch003.indd Sec1:101
ch003.indd Sec1:101 3/8/11 6:09:10 PM3/8/11 6:09:10 PM
www.EngineeringBooksPdf.com
Platform-to-tool data exchange can be complex. Extracting the stick and node model for a structural analysis and determining the relevant loads is not yet a common automated translation, as it requires human expertise and judgment (Emkin 1988). Similarly, energy analyses have had building mod- els specially developed for their input, but these are not defi ned in a model structure that a designer would use, requiring the development of a new or heavily revised model to undertake the energy analysis. These exchanges are complex because of the special geometry the tools require. Eventually, we will see robust and competent automatic translations from design-oriented models;
in the meantime, interactive manual translations will be required.
More straightforward are tool-to-tool exchanges. These are limited because of the limited data available within the exporting tool. One example is the translation of a quantity takeoff (QTO) to cost estimating application.
Here the QTO extracts BIM data that has multiple potential uses for cost esti- mating, later for purchasing and materials tracking, or maybe to associate with work packages and scheduling. Another tool-to-tool interface is the use of a lightweight geometric viewer, considered here as a BIM tool, such as Autodesk Design Review (using DWF format) or Adobe’s 3D viewer (using PDF for- mat). These tools have their own design uses in visualization and review. They are also promoted and can be used for limited application as interfaces for other tools, such as lighting simulation or clash detection. In these cases, the boundary between a design platform and a tool is fuzzy. The bottom line is that lightweight geometry viewers cannot implement design changes and cannot update the model in the platform; the information fl ows are one-way.
The major challenge of interoperability is platform-to-platform exchange.
This includes design platforms such as ArchiCad, Revit, and Digital Project and fabrication model platforms such as Tekla, SDS/2 Structureworks, and StruCad, CADPipe, and CAMduct. Platforms not only incorporate a broad spectrum of data, they also incorporate rules that manage the objects’ integ- rity. Consider the “building core” custom parametric assembly described in Chapter 5, Section 5.4.1. The rules for its layout and updating were developed by the architectural fi rm that developed it, based on the experience of pro- ducing many dozens of high-rise offi ce buildings. While it is straightforward to pass a fi xed instance of the building core object to another application, passing an editable model would require passing the rules, some embedded in spreadsheets, to the receiving platform. Today, there is only limited similar- ity of the rule sets supported by the different BIM platforms (as described in the Commonly Asked Questions in Chapter 2 Section 2.3.6. Similarly, a wall assembly in some BIM platforms has its own application of those rules, possi- bly with embedded objects such as framing, with rules applied to the framing.
ch003.indd Sec1:102
ch003.indd Sec1:102 3/8/11 6:09:10 PM3/8/11 6:09:10 PM
www.EngineeringBooksPdf.com
In such cases, platform-to-platform exchange is not possible. It should be emphasized that the exchange of fi xed shape objects and even some simple extrusions are not problems. At some point in the future, a standard vocabu- lary of rules may be developed, which could lead to solving this platform-to- platform exchange of parametric models.
More generally, an issue growing out of interoperability is the need to man- age the multiple representations of a project, at the platform and tool levels.
The need is not to just translate an architectural model to another format, but to modify or extend the model information so that it represents the design for different uses. The structural design example discussed above indicates the knowledge required to translate a physical model of a structural design into a model for structural analysis. The derivation of a structural model from a physical model involves many specialized considerations, dealing with struc- tural codes, spans, depth of beams, the behavior of connections, and especially loading conditions. Expertise in structural engineering is required to defi ne the analytical model of a building from its architectural incarnation (Emkin 1988). Also, the structural model may take alternative forms, usually a stick and node representation characterizing the structure’s topology for transmit- ting its behavior (see Figure 3–1(left)). The model carries abstract represen- tation of connection behavior, external loads, and the code requirements to address load combinations. Some particular parts of a structure, because of its geometrical or loading complexity, or their criticality to the project, may be represented as a mesh in a 3D fi nite element model (FEM), with a much more detailed geometry whose interfaces defi ne a different set of nodes and element requirements (Fig 3–1(right)). This is not a solid model, but rather a packed set of cells that are able to describe their behavior within the framework of the other cells. FEM models are typically derived from solid models with signifi - cant human input. The generation of both types of structural models requires structural design expertise. And we can have two and sometimes more repre- sentations of a building’s structural members.
The major point is that as changes are made to one model, the consist- ency of other models requires them to be reviewed and possibly updated.
Currently, almost all of this updating and management is carried out manu- ally and laboriously. Changes propagate and management of propagation is a fundamental aspect of design coordination. These are the broader issues of interoperability.
Why should architects, contractors, engineers, and fabricators be inter- ested in interoperability and product models? Aren’t these technological issues for computer scientists and software companies to resolve? Why is this chap- ter important to read and understand?
ch003.indd Sec1:103
ch003.indd Sec1:103 3/8/11 6:09:10 PM3/8/11 6:09:10 PM
www.EngineeringBooksPdf.com
Standards have played and will continue to play important roles in AEC business practice—material performance standards, graphic standards, stand- ards for defi ning products, drawing set standards, classifi cation standards, lay- ering standards. Some standards are to help people understand each other.
Since building information model standards are digital, the development of such standards also are digital. Computer scientists can and have implemented the technological framework for interoperability, by providing the languages (EXPRESS, BPMN, XML, and others are being explored) that support exchange protocols. Architects, engineers, contractors and fabricators, however, are the knowledge experts that know what the information content of an exchange should be. In AEC, no one organization has the economic clout or knowledge to defi ne effective interoperability for the whole industry. User-defi ned exchange standards seem an imperative. Consider the meaning of r-values, lumens, ther- mal breaks, and wythe.1 Different construction domains defi ne needed terms and these are part of that fi eld. In some ways building model exchanges deal with the varied building information with which a fi eld works.
Interoperability, then, involves mapping specifi c model information from that defi ned for one application to the logically consistent information required for another application. In simple cases, the translation is syntactical and does not involve changes in meaning. However, many exchanges require embedded expertise that interprets the design information with one meaning to other information with other meanings. A familiar example would be translating
FIGURE 3–1 Two different types of analytic structural models: a deformed stick model of a structure and a 3D solid fi nite element model of another structure.
(Waller Marine, Inc.)
1A continuous vertical section of masonry one unit in thickness, typically called out on wall sections.
ch003.indd Sec1:104
ch003.indd Sec1:104 3/8/11 6:09:11 PM3/8/11 6:09:11 PM
www.EngineeringBooksPdf.com
an architect’s building model to one used for energy analysis. In that conver- sion, the meaning of all space boundaries dramatically changes. All building projects, by the time they are built, involve both these kinds of translations.
These meanings are defi ned by the fi elds that use the data. Methods for defi n- ing these exchanges are the focus of the fi rst part of this chapter. The second part focuses on the issues and methods for synchronizing and managing the multiple representations of a building project and the management of these heterogeneous representations.