3.1INTRODUCTION
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 computer applications. Beside the capability to support geometry and material layout, 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 application. Manual copying of partial project data greatly discourages iteration during design, as required for finding best solutions to complex issues, such as structural or energy design. It also leads to errors, where manual copying inevitably 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-businesscould only work without personal accounts, requiring you to enter your full profile each time you used the site; tracking of your order would not be practical. 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 translators 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 difficult? The reality is that we have moved past the modeling of shapes and geometry to the modeling of objects—first 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 behaviors, 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 supporting 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, specific portions of the platformrsquo;s native data model (the data structure that the platform uses internally) are translated. The translation is realized by defining the needed model data on the platform (called a model view) and putting that data into the format needed by the tool and filling 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 platformrsquo;s native building model. The BIM toolrsquo;s results inform the platform user, and the user updates the original model. In a few cases the toolrsquo;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 fundamental form of interoperability and is supported by both direct applicationto-application exchange and also through shared neutral exchange formats, such as IFC.
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 models specially developed for their input, but these are not defined 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 estimating, 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 Adobersquo;s 3D viewer (using PDF format). 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 i
剩余内容已隐藏，支付完成后下载完整资料
文献题目：BIM Handbook——Interoperability Introduction
BIM手册——互操作性介绍
3.1INTRODUCTION
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 computer applications. Beside the capability to support geometry and material layout, 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 application. Manual copying of partial project data greatly discourages iteration during design, as required for finding best solutions to complex issues, such as structural or energy design. It also leads to errors, where manual copying inevitably 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 could only work without personal accounts, requiring you to enter your full profile each time you used the site; tracking of your order would not be practical. 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 translators 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 difficult? The reality is that we have moved past the modeling of shapes and geometry to the modeling of objects—first 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 behaviors, 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 supporting 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, specific portions of the platformrsquo;s native data model (the data structure that the platform uses internally) are translated. The translation is realized by defining the needed model data on the platform (called a model view) and putting that data into the format needed by the tool and filling 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 platformrsquo;s native building model. The BIM toolrsquo;s results inform the platform user, and the user updates the original model. In a few cases the toolrsquo;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 fundamental form of interoperability and is supported by both direct applicationto-application exchange and also through shared neutral exchange formats, such as IFC.
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 models specially developed for their input, but these are not defined 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 estimating, 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 Adobersquo;s 3D viewer (using PDF format). These tools have their own design uses in visualization and review. They are also promoted and can be used f
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[469137]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
