Chapter 2 Discussion Questions
3.5 THE EVOLUTION FROM FILE-BASED EXCHANGE TO BUILDING MODEL REPOSITORIES
3.5 THE EVOLUTION FROM FILE-BASED EXCHANGE TO
corruption. First, all operations in an application are logically taken on a copy of the current dataset. If the dataset was good, that is, in database terms had
“integrity,” we do not want to overwrite it until we have achieved integrity in the copied version. When that state is achieved in the eyes of the user, an appli- cation can ask to SAVE the modifi cation, or in a database, we execute a COM- MIT. In both of these cases the initial write is done fi rst to a new place in
Base Requirements for a BIM Repository
The base requirements for a BIM repository are fairly straightforward. Some are common to most database management systems. Others are basic needs articulated within the AEC industries and can be summarized as follows:
User access control provides access and read/write/create capability for different levels of model granularity. Granularity of model access is important, since it identifi es how much model data must be impounded for a user to revise it.
Represent users associated with a project, so their involvement, access, and actions can be tracked and coordinated with workfl ows.
Read, store, and write both all-native data models of platforms and also the derived data mod- els used by other various BIM tools.
Read, store, and write open standard model data models for some interoperability workfl ows and for project management.
Manage object instances and read, write, and delete them based on update transaction protocols.
Support product libraries for incorporating product entities into BIM models during design or fabrication detailing.
Support storing product specifi cations and other product maintenance and service information, for linking to as-built models for owner handover.
Store e-business data, for costs, suppliers, orders shipment lists, and invoices for linking into applications.
Provide model exchange capabilities for remote users, for example, Web access, FTP fi le exchange, PDF, and XML.
Manage unstructured forms of communication: email, phone records, notes from meetings, schedules, photographs, faxes, and videos.
These provide basic content capabilities of a BIM server. However, these capabilities do not address how complex object models and all their ancillary data should be managed.
•
•
•
•
•
•
•
•
•
•
ch003.indd Sec8:137
ch003.indd Sec8:137 3/8/11 6:09:30 PM3/8/11 6:09:30 PM
www.EngineeringBooksPdf.com
storage (in case there is a power outage during the write), then the directory reference is shifted from the old to the new version of the fi le. This transaction approach is designed to address power outages, disk corruption, errors in pro- grams, and other issues that can corrupt a dataset (but not user error). Most applications today rely on this protocol.
Transactions are easy for single-user applications and for updates that can address the whole fi le. Of course your bank’s database and soon your project’s database has no notion of a whole fi le but rather varying levels of granularity upon which transactions apply—at the project, building, object, or potentially even attribute set levels of granularity. Also, we may have doz- ens of users. ATMs make bank database transactions using simple locking mechanisms that only allow access to your account information serially. That is, you and others who share your account can only act on it one at a time.
This works because your transactions—involving both read (current balance) and write (withdrawal or deposit)—take only a few seconds. The recognition that the time between reading engineering data and later writing it may take several hours or a day introduced new transaction problems, classifi ed as “long transactions” (Gray and Reuter 1992). In general, guaranteeing the integrity of design, engineering, and construction transactions with a building model server using concurrent, long transactions is a fundamental requirement for a building or product model server. Transaction capabilities are fundamental, and apply to single, parallel, or “cloud” confi gurations of servers.
A transaction is both the unit of change and also a unit of consistency management (or synchronization). A system’s transaction management system determines how concurrent work is undertaken and managed, for example, by managing partitions of the building model at different levels of granular- ity (which might be a fi le, a fl oor level, or a set of objects). The information granules may be locked allowing only single users to write, or allowing sharing by multiple users to write data but with automatic notifi cation of updates, and other concurrency management policies. These will become more important as we move to object-level management of data, potentially allowing high levels of concurrency. Today, most transactions are directly initiated by human users and only apply to a fi le system or server. But many engineering database trans- actions will become active, in that they may fi re automatically, for example, to identify a change in read-only objects being used by others, or to update a report when the data the report was based on has been updated.
An important goal capability of a BIM server is project synchronization.
While change management means that manual or interactive methods iden- tify when fi les may not be consistent and may require revision as the result of other changes, synchronization means that all the various heterogeneous
ch003.indd Sec8:138
ch003.indd Sec8:138 3/8/11 6:09:30 PM3/8/11 6:09:30 PM
www.EngineeringBooksPdf.com
project fi les are maintained so as to be consistent with one another. It is a fun- damental aspect of model integrity, but is now largely managed manually.
While a single parametric model platform and the generation of multiple 2D drawing views and schedules resolves synchronization among a set of drawings derived from the same model, it does not resolve the case involving multiple functionally different models running on tools that are derived from the platform model. Even less easily synchronized are multiple platforms’
models, say, used in different fabrication processes on the same project.
Here, synchronization addresses all the coordination issues among the dif- ferent systems, including spatial clashes, intersystem connections and load transfers between systems (energy loads, structural loads, electrical or fl uid fl ow loads). Synchronization across heterogeneous models is largely carried out manually but is one of the major benefi ts of an effective BIM repository.
Manual methods of data consistency management have been relied on, but are onerous, as they help only a little when it is known that the informa- tion in one fi le depends on the contents of another fi le. Human management based on objects (carried in one’s head) does a better job. But if synchroni- zation is to be realized at the object level, with millions of objects, manual maintenance is not practical and automatic methods will have to be imple- mented and relied upon. It should be noted that the updating associated with synchronization cannot yet be fully automated, as many revisions to achieve consistency involve design decisions; some aspects of synchronization require person-to-person collaboration. So automatic synchronization can only now be achieved in degrees.
A framework that allows object-level coordination across heterogeneous project models generated by different products is required to achieve any level of synchronization, manual or automated. Such a framework has implications for the modeling tools integrated. All objects need to carry timestamps and global IDs. Global Unique IDs (GUIDs) identify an object regardless of what application is using it, so that updates can be synchronized across heteroge- neous applications and potentially allow aspects of objects to be updated by different users, a sometimes important requirement. Consider a collaborat- ing architect and energy analyst; the analyst is likely to be assigning material properties to a model prepared by the architect. The analyst is changing data that may affect other model properties, such as those for acoustic assessment.
GUIDs allow reliable tracking and management of such changes. The times- tamps are updated whenever a fi le is modifi ed and allows tracking of the most recent version. GUIDs and timestamps are examples of the metadata carried in a building model. Metadata was coined as a term to addresses “the data about the data,” allowing it to be managed.
ch003.indd Sec8:139
ch003.indd Sec8:139 3/8/11 6:09:30 PM3/8/11 6:09:30 PM
www.EngineeringBooksPdf.com
These capabilities require that any application that can create, modify, or delete the design or engineering data must support:
Creation of new GUIDs and timestamps, whenever a new object is cre- ated (or stored) or exported
Reading the GUIDs and timestamps with imported objects and carrying this data for later export
Exporting the timestamp and GUID data with other exported data and objects that have been created, modifi ed, or deleted
In Chapter 2 we listed the information needed for object-level version management—here, what we have called synchronization. In Table 3–3 we identify the ability of the BIM authoring tools to support object-level change management.
These criteria apply to all data that will be managed by a server, whether using IFC or not. That means that it applies to most BIM tools, as well as platforms. If a quantity takeoff application extracts a set of quantities from a BIM model, the timestamps on the quantities will determine their later version validity. When a product specifi cation is changed in a spec-writing application for some component, say, a set of windows, that change may affect quanti- ties of different window types, installation requirements, detailing, and other aspects. The change needs to propagate to all affected information. Given the tracking of the version of all object instances makes it possible for automatic management of synchronization.
Synchronization guarantees that all data has been checked to be consistent up to the most recent timestamp. Synchronization is not addressed in the mid- dle of some design activity, such as when one temporarily saves current fi les at
•
•
•
Table 3–3 Synchronization of Object Metadata for a Selected Set of BIM Platforms
BIM Platform Manage Unique IDs Manage Timestamp
Revit, Release 2011 Has a tag object that can carry ID at the object instance level
At the fi le level
Bentley At the object instance level Modifi cation marks carried in object
ArchiCad At the object instance level At the object instance level
Vectorworks No support No support
Digital Project, V1, R4, SP 7 At the object instance level At the object instance level Tekla At the object instance level At the object instance level
ch003.indd Sec8:140
ch003.indd Sec8:140 3/8/11 6:09:31 PM3/8/11 6:09:31 PM
www.EngineeringBooksPdf.com
dinner time. It applies only when changes are considered adequate for external sharing and review. These are when Commits are made. Objects that are not current, not synchronized, should not have their data exported to other sys- tems. This may result in propagating erroneous data; only fully synchronized objects should be the basis for exchanges. Status fl ags are often carried at the object level in order to distinguish temporary updates from complete transac- tions, and also objects lacking synchronization. Based on such status infor- mation, a background transaction identifi es what objects have been created, modifi ed, or deleted, and identifi es what other fi les have those objects within them. Alternative mechanisms can be applied to fl ag the affected objects in the different application datasets. After identifying the potential inconsisten- cies, the type of synchronization transaction determines which are manual and which are automated:
1. Automatic Partial Updates: Many derived object views are simple and