Drawing Management Brain Dump Paul McArdle Autodesk, Inc. April 11, 2003 This brain dump is intended to shed some light on the high level design philosophy behind the Drawing Management feature and how this philosophy is reflected in the feature. It is not intended as a tutorial, an overview of the user interface or as an outline of the Drawing Management process. The documentation for Drawing Management is excellent and does a tremendous job of explaining what this feature is and how to use it. This brain dump is intended to outline the higher level concepts that drove the design and implementation of this feature. Hopefully by shedding some light on the concepts and goals for this feature it will be easier to understand some of the intricacies of this feature and perhaps understand why the Drawing Management feature is what it is. The standard This is solely my individual opinion and should not be construed as an official Autodesk statement yadda, yadda, yadda. disclaimer applies. Drawing Management Goals The stated goals of Drawing Management in Autodesk Architectural Desktop (ADT) 2004 were to formalize the Building Information Model (BIM) and to help automate the drawing management tasks involved in using ADT to design and document a building. We set out to craft a flexible solution using primarily the tools available to us with the AutoCAD platform, and leveraging the processes that our users were already using in the field. Targeting larger commercial, institutional and multi-family projects led us to design a system where each level of a multi-level building is modeled in a separate drawing file. Each level may be further subdivided into multiple drawing files to support a large team size, multiple disciplines, smaller
file sizes and better performance. The entire Building Information Model can be assembled by externally referencing (xrefing) these separate drawing files together. I will refrain from arguing the advantages and disadvantages of a distributed Building Information Model versus a centralized Building Information Model. Suffice it to say that some users do implement ADT as a centralized Building Information Model where the entire Building Information Model and documentation reside in a single drawing file. This approach seems popular for single family home design. Because of the limitation that only one person may edit a drawing file at a time, most users opt to distribute the Building Information Model across multiple drawing files. Drawing Management was designed for this type of distributed Building Information Model approach. Jim Awe outlines some of the advantages to the Building Information Model in his Philosophical Brain Dump on ADT. In the document, Jim points out that because you have a real model of a building and not just a picture of one, you can ask it building specific questions like: egress analysis, heat loss analysis, code compliance. Historically, AutoCAD and ADT have left users to manage the numerous files that were required to design and document a building. Individual files had no knowledge of there relationship to the Building Information Model. Third party applications did not know which drawing files represented the actual Building Information Model versus which drawings files were reports or supporting files. Drawing Management formalizes the structure of the distributed Building Information Model to allow users and third party developers the ability to identify, organize and manage the Building Information Model and other supporting files. This formalization of the Building Information Model will help achieve Jim Awe s goal of this project (ADT) to find a way that the Building Information Model could be shared by the entire community". Downstream applications (Estimating, Code Compliance, Energy Analysis, Facilities Management, etc), are now easier for developers to write, because they don't have to partner with 1 or more other 3rd party developers. They have a single model to leverage. Projects Drawing Management supplies a framework for formalizing the Building Information Model and organizing project files. This framework is implemented as an XML schema that contains centralized general project information and individual labels for each drawing (dwg) file associated with a project. This XML schema allows the project related information and project structure to be stored outside of the drawing files. Externalizing the project structure from the drawing files allows ADT and third party applications to recognize and contribute to the project structure without having to open and read the individual dwg files. This external project structure is also easily extensible and allows for support of other file types to be displayed and managed in one central project navigation user interface. There is no reliance on ADT information or objects in the drawing files to support the project schema. This means that the Drawing Management feature can be used to manage vanilla AutoCAD drawings without introducing ADT objects into the drawings. This external project structure also makes it very easy to create a project navigation application that is not dependant on AutoCAD. At the highest level of organization, Drawing Management has implemented projects. A project represents a single building project. In ADT 2004, projects may not be nested. General project information is stored in a shared XML file with an.apj extension. The project.apj file is home for common project information that can be shared across the project. This information includes the
Project Name, Number, Description, Project Bulletin Board, Project Image, default drawing templates, level information, division information, and project details. A project does not store a list of project drawing files or their relationships. Labels containing project related information for the individual drawing files are stored in an XML file that accompanies each dwg file in the project. The list of project dwg files and their relationships are determined dynamically at run time by evaluating the XML schema. The project structure is also mirrored in the folder structure on disc. This approach was adopted to make the project structure visible in the windows file system and to facilitate project back-ups, restores and archiving. Building Information Model Versus Reports The Building Information Model process offers the ability to model the building once and the plans, elevations, sections, schedules, etc. fall off the Building Information Model. In theory, the Building Information Model uniquely describes the building itself. Plans, sections, elevations, schedules, etc. are merely reports that are extracted or generated from the Building Information Model. The distinction between the Building Information Model and the data extracted from the model to generate reports is an important distinction. To illustrate this further, imagine fully designing a digital 3D Building Information Model. The 3D model is complete to a level that you simply give the digital 3D model to the contractor to build from. You do not deliver any traditional drawings because the information is embedded in the digital 3D Building Information Model itself. The contractor is free to slice and dice the digital Building Information Model as needed to obtain any necessary information. The contractor can query/view/plot portions of the building to generate plans, sections, details as required for take offs, procurement, tasks allocation, coordination, etc. In this example, the digital 3D model you produce is the Building Information Model. The different plans, elevations, schedules, etc. that the contractor generates to help communicate the building design during bidding and construction are simple reports extracted or generated from the Building Information Model.
Drawing Management respects this distinction between the unique Building Information Model and reports generated from the Building Information Model. This is an important distinction that will be key in understanding various feature behaviors, especially the annotation and scheduling system. The Building Information Model The primary Building Information Model drawing file type is a Construct (n). A Construct contains objects that uniquely describe a specific built portion of a building. When creating Constructs, you assign the Construct to a unique location within the building. The Building Information Model is comprised entirely of Constructs. Objects in Constructs represent a one to one correspondence to the built building. This can simply be a single drawing file that contains the walls, doors, windows, etc. that represent the first floor of a building. The objects that represent the second floor would be in a separate Construct. A single level of a building may be sub-divided into multiple Constructs. To assemble the entire Building Information Model, all of the appropriate Constructs are externally referenced (xrefed) together in a single dwg file.
Users are free to determine the number and organization of Constructs within a project. This open-ended project structure places the burden on users to determine their own optimal project structures. Although this places an initial burden on users, this flexibility will allow users to adapt Drawing Management to there own specific project types and organization. This flexibility was preferred over providing pre-determined project structures that may prove unusable for individual users or project requirements. Repeated Building Elements One of the greatest powers of external references (xrefs) and blocks in ADT is the ability to reuse geometry in order to gain productivity. One of the premises of Building Information Modeling is to model things once and view the model is various ways. Model a wall once and you automatically get plan, elevation and section. You do not have to draw the wall twice. Taking this a step further, you can draw your building core once. Draw the building core elevator, stairs, bathrooms once and xref them into each level. In the past, there were issues when attempting to distinguish one reference of these building objects from another, for example the second level core from the third level core, etc. The issues resulted from the fact that these were the same identical objects that were copied or referenced into multiple levels. In order to support this external reference process to reuse geometry in the Building Information Model, we need to be able to distinguish the unique building objects, and unique copies of building objects that represent the unique Building Information Model. Let s take a very simple case to illustrate this point. If we take the case of an office that we want to xref into multiple portions of the Building Information Model. Assume that you have a drawing file within the project with the walls and a door that represent the office. We then reference this office into the first level. We also reference this office on the second level. Now you want to know how many doors are in the building. A simple scan of all the drawings in the project will give you a total of three doors, the door on the first level, the door on the second level,
and the original door in the office drawing. But this is not correct. There are really only two doors in the building, the ones on the first and second level. We need a way to distinguish the door in the original office drawing from the copies of the door that represent the unique built doors within the Building Information Model. In order to support this concept of repeated objects in the Building Information Model, a second Building Information Model type is needed. This additional drawing file type is called an Element. Individual isolated Elements are not considered to be part of the Building Information Model. Elements become incorporated into the Building Information Model when they are xrefed into Constructs. In the example above, the office would be created as an Element. This office Element is then xrefed into the first and second level Constructs. When determining the number of doors in the Building Information Model, only the doors that are inserted or referenced into Constructs are counted. We therefore get the correct answer of two doors, the one xrefed into the first level Construct and the one xrefed into the second level. The door in the office Element is not counted. Objects need only be created as Elements if they are going to be repeated within the Building Information Model. If objects represent a unique portion of the Building Information Model they should be created directly in the appropriate Constructs. The majority of building objects will typically be created and reside directly in Constructs. Important Note: Constructs should not be nested; a Construct should not xref attach another Construct. Nesting Constructs in this manner will result in unexpected results when generating views and when using the scheduling system. Constructs may be xref overlaid into one another for reference when modeling in Constructs, just not xref attached.
Model Views Now that we have defined the Building Information Model we can move onto extracting data from the model to generate reports. As mentioned previously, floor plans, elevations, sections, schedules, etc are considered reports that are extracted from the Building Information Model. Envisioning the Building Information Model as a relational database may help in understanding the functionality of Model Views. Please note that in ADT, Model Views are simply referred to as Views, however I will refer to them as Model Views to hopefully avoid confusion with AutoCAD named views. Within the Building Information Model database, objects can be labeled in a few ways to allow then to be retrieved or queried from the database at opportune times. Model Views allow you to query Constructs based on these labels. For example each object (wall, door, window, etc) in the Building Information Model database is labeled, or can be identified by its location within the building. As you recall, all Building Information Model objects reside in Constructs. Each Construct is assigned a location (level/division) within the Building Information Model. Each object contained in the Construct inherits the Construct s location with the Building Information Model. Levels and Divisions Locations are defined by the Levels and Divisions defined within a project. Levels are synonymous to floors within a project. Divisions are intended to be used to identify portions of the building such as wings. A Construct s location is the combination of the Level and Division to which it is assigned. This location property of a Construct allows it to be queried and included or excluded in a Model View based on this location. For example a Model View may retrieve all Constructs for the first level, the second level east wing (division), or all Constructs for the entire building (all levels, all divisions).
It is possible for a Construct to span multiple locations within the Building Information Model. This facilitates the use of objects like Curtain Walls that are modeled as a single object that spans multiple levels of a building. When a Construct spans multiple locations, the objects in the Construct are shared by multiple locations. This does not mean the objects in the Construct are copied in each location. Take for example a curtain wall that spans three levels. When generating a view of each individual level, each will share the geometry of the curtain wall. Even though the curtain wall appears in a model view of each level, there is only one curtain wall in the Building Information Model. The Global Cut Plane feature will facilitate the proper display of spanning Constructs at each level.
Categories In addition to the location property, a Construct may also be categorized to provide another label and level of control for Model View queries. By creating categories and sub-categories on the Project Navigator Constructs tree, Constructs can be organized into logical groups (categories) that can be included in or excluded from Model views. For example, Constructs may be categorized as Exterior Shell, Tenant Fit Up, Building Core. When generating a view, it is possible to extend the query to include this additional label such as include the first level exterior shell and building core, the second level east wing tenant fit up, or the entire building (all levels, all divisions) exterior shell. Based upon these queries, the model views will automatically scan all the Constructs and include those that match the query criteria. The appropriate Constructs will be referenced at the proper elevation when more than one level is included in the Model View. The real power in categorizing Constructs is realized by opting to include Construct categories in Model Views, rather than individual Constructs. This is done by checking the Construct category (folder) rather than checking the individual Construct in the Model View contents tree. By including the category, any new Constructs that are added in that category that meet the Model View query will be included in the Model View the next time it is regenerated. Regenerating a Model View will rerun the model view s query and make any changes to the model view required by the updated query results.
For example, when creating a second level model view I indicate that it should include the furniture Construct category. At the time I create the model view, there is no second level furniture Construct so none is included in the model view. Later, I create a second level furniture Construct (assign it to the second level) and place it in the furniture Construct category. When I regenerate the second level model view, the model view will include the furniture Construct category, find the second level furniture Construct, and automatically include it in the model view. Leveraging this behavior is an easy method of ensuring that everyone in the project references the proper files. For example, changing the curtain wall that is referenced by multiple Model Views across multiple levels of the Building Information Model is as easy as changing the curtain wall Construct assignments. Right click on the old curtain wall Construct on the Constructs palette and click properties. Remove all assignments for this Construct. Right click on the new curtain wall Construct, click properties and set the appropriate assignments. Now, when any model views are regenerated, any references to the old curtain wall Construct are removed and replaced with a reference to the new curtain wall Construct. Sheets A Sheet represents a plotted document. Once a Model View is created, it may be dragged and dropped into a Sheet. Dragging a Model View onto a Sheet layout, will result in the objects in the model view being referenced into the sheet s model space, a viewport being created and the appropriate zoom factor being set for the viewport. The viewport size and zoom factor is determined by the viewport default properties of the Model View.
A Model View represents a set of objects extracted from the Building Information Model. Model Views may be reused within the project. A Sheet is a unique document. For example, if you create a model view of the first level, this Model View may be used in one Sheet as the floor plan, a second Sheet as a reflected ceiling plan, and in a third Sheet as a furniture plan. A different display configuration can be used in the Sheet view ports to display these different plan types. It is also possible to create distinct Model Views for each plan type if desired. Annotation ADT 2004 has made several improvements to the tagging and property set functionality to support the distributed Building Information Model. First is the ability to tag an object in an xref. This allows annotation to be placed in Model Views and Sheets while the objects reside in Constructs. In the Drawing Management process, a user will create a Construct for the first including walls and doors. This Construct will then get (automatically) referenced into a Model View of the first level. This Model View will then get dragged and dropped into a Sheet. A door tag is annotation and should be included in a report rather than in the actual Building Information Model. The Model View and Sheet are reports extracted from the Building Information Model. So the door tag should be placed in either the Model View or Sheet. The tagging mechanism has been modified in 2004 so that when placing a tag you can select individual objects within xrefs. Second is the ability to place property sets at the proper location within the Building Information Model. In the example above, the door tag is annotation and as such, it belongs in a report (Model View or Sheet), and not in the Building Information Model (Constructs). This is true for the tag itself, but not the property sets. The property sets contain information about the actual building objects themselves and belong in the Building Information Model Constructs. Taking the above process of tagging the door in the Model View or Sheet, the tag resides in the report (Model View or Sheet) but the property set needs to be attached to the door within the Building Information Model Construct. The tagging mechanism in ADT 2004 recognizes the project structure and will automatically place the property set at the proper location within the Construct, even when tagging in a Model View or Sheet.
Third is the ability to attach a unique property set to each copy of an xref. This functionality is needed to properly assign property sets to Elements that are repeated within Constructs in the Building Information Model. In the example above with the office Element repeated in the first level Construct and the second level Construct assume the door on the first level is a Cherry wood door while the door on the second level is a Birch wood door. Even though within the Building Information Model these are copies of the same source door object (within the office Element) we need to uniquely describe each copy as if it was a unique door. In ADT 2004 users are able to attach property sets to xref instances. This allows us to uniquely describe the copy of the door on the first level independently of uniquely describing the copy of the door on the second level. User Interface There are two basic User Interface components to Drawing Management; the Project Browser and the Project Navigator. The Project Browser is for creating new projects, navigating to existing projects, and setting the current project. The Project Navigator allows for navigating within the current project. Refresh Both the Project Browser and Project Navigator have a refresh option. The refresh becomes important in a multi-user environment. Information on these dialogs is pulled from the project information stored on disc. Changes made by another user to the project information on disc will not immediately be displayed on all user s screens. In a multi-user environment, users will need to refresh the dialogs periodically to ensure that the information in the palette and dialog accurately reflects the information stored on disc. Re-pathing The Project Navigator provides a great amount of drag and drop functionality within the project navigator as well as between the drawing window and Windows Explorer. This allows for the easy renaming, movement and categorization of files. Objects may be dragged from the drawing window and dropped on the Project Navigator to move and copy objects between files. The Project Navigator also provides a re-pathing mechanism to repair xref paths with the project that may become broken by moving or renaming files on the project navigator. The Project Browser stores up a list of changes made on the navigator that may cause xref paths to become broken. The re-pathing operation will scan all files within the project and repair any paths broken by these changes. Re-pathing is a manual process. The list of changes is stored up in memory for the current project within the current editing session. Users will be asked if they wish to re-path when setting a different project current. User will unfortunately NOT be reminded to re-path when closing AutoCAD. If re-pathing is not performed prior to shutting down ADT or changing the current project, then the list of changes is lost and any broken xref paths will remain broken. The re-pathing option was limited to a manual process due to potential performance problems on large projects. As a result, it should be stressed to users to re-path very often and prior to shutting down ADT. If an entire project moves (the path to the project apj file changes) users will be asked if they wish to re-path the entire project. If the project is not re-pathed at this time, the opportunity to re-path the project is lost.
Summary Although the initial implementation of the Drawing Management feature achieves the goals for the feature stated above, there are many more things that we can do with this feature. There are areas where the process can be smoothed a bit more and where more automation may be introduced. We look forward to further developing this feature and to incorporating functionality that we did not have time to include in ADT 2004. The real potential this feature introduces is for additional features that can leverage the formalized Building Information Model and knowledge of a project. This will make it much easier for third party developers to develop applications that rely on being able to identify and assemble the building information model. Tremendous opportunities open up now that specific project drawing files can be identified as Building Information Model files and can be assembled in the proper relationship to each other. Objects within these drawing files can determine which unique portion of the building model they represent. You can begin to see this in the project based property set definitions that allow for spaces to automatically include the projects Level ID as the prefix to the space number (ie 101, 201, etc). The initial reaction to this feature is often that it appears very complex. On the one hand, we are dealing with some complex concepts revolving around formalizing a distributed Building Information Modeling process. On the other hand, we believe that the concepts and processes that have been formalized within this feature should align with most users current processes. It may require users re-think and formalize their own current process in new terms (Elements, Constructs, Views, Sheets). These new terms, although not the most architectural of terms, do represent some relatively simple concepts. Once these concepts are understood, this feature offers many tools for easily manipulating the objects and files within the Building Information Model and a project. We hope that this feature will prove to be a useful tool in managing your projects and increasing productivity.