BIM Beyondd Autod

desk® Navisw
works®:
Linking You
ur Navisworks
s Model to an External
Data
abase
Greg Weesner – Autoddesk, Inc.
al Consultant - Developer
Technica
Autodesk
k Global Serv
vices

CP3271
1: Anybody who
w is serious
s about Building Informatio
on Modeling (BIM) knows tthere is more to
BIM thann the data stored in the mo odel. The morre involved the e BIM implem mentation beccomes, the mo ore
importannt it becomes to store inform mation in an external
e data base. Autode esk Navisworkks software iss
primarily a collaboratio
on tool and as such presents unique ch hallenges and d unique oppo ortunities overr
authoringg tools. Taking full advanta age of a databbase can auto omate coordination tasks, improve
communication, tighte en collaboratio on, enhance 4D4 and 5D si mulations an d create a mu uch more
enhance ed overall BIM
M experience. Passing data a between ap plications is e easy, but finding the propeer
strategy for implemen ntation is critic
cal for succes
ss. This class will outline se
everal opportunities for
connecting Naviswork ks to a databa ase as well as
s identify the key elementss of a successsful
implementation strate egy.

Learnin
ng Objectiv
ves
At the en
nd of this class, you will be able to:
 Crea
ate a strategy to sync data between Nav
visworks and an external d
database
 Succ
cessfully leverage an exterrnal database
e to improve ccollaboration
 Imple
ement key da
ata design prin
nciples for effficient modeli ng and collab
boration
 Succ
cessfully conn
nect Navisworks to an exte
ernal databasse

About tthe Speake

er
Greg haas a bachelo or of architeccture and a master
m of sciience in arch
hitecture from Cal Poly, San
Luis Obispo. After graduating
g frrom Cal Polyy, Greg workked in the arrchitecture in
ndustry for five
years ass a CAD manager and projectp mana ager. Greg aalso taught ppart-time at th
he Napa Valley
College ATC®. This s included alll levels of AutoCAD® an nd Architectture productss. After attaiining
hitect’s licens
his arch se he took a job with Autodesk as a QA enginee er, then as a software
engineeer working on n the AutoCA AD platform team. In 20007, Greg mo oved to Auto odesk Consu ulting
in the AEC Division to get more e exposure to o the AEC inndustry and p products. Hee currently
specializ
zes in buildinng custom applications
a for Autodeskk® AEC cusstomers.

Email: greg.wesner@
g @autodesk.com
 Linking Your Navisworks Model to an External Database

Leveraging the “I” in BIM

Building
The meaning of the word ‘Building’ within BIM is beginning to widen. BIM used to be about just
modeling a building. Then it grew to modeling the building and adding additional information
(which we’ll get to in a minute). More recently we have begun to see the modeling of much more
than just the building. BIM is beginning to include modeling the site around buildings, piping for
plants and refineries, factories and the equipment inside that is being used in production.
Building in BIM used to be a noun representing an object. Now I think it is growing into a verb
meaning anything that can be Built can be modeled.

Modeling
Modeling primarily gives you the ability to visualize a design. In-and-of-itself, this is a huge step
over drawing 2D plans. It reduces errors and is a much better communication tool. Tools begin
to evolve though and even just the modeling can be leveraged for more than just visualization.
Tools such as Autodesk® Navisworks® can be used for interference checking and construction
simulation. This requires some additional information, but is primarily using the 3D model to
perform these tasks.

Information
And so we get to the “I”. In my opinion, Information in BIM is the fastest growing area of this new
revolution. In my current position I have the benefit of working with some of the largest and most
varied Architecture, Engineering and Construction (AEC) firms in the US and around the globe.
Not a week goes by where I am not asked to meet with a new client about extracting data out of
Revit, AutoCAD, Navisworks or one of our other products and into a database, a spreadsheet or
to another tool to process data.

The primary form information takes is Data and/or Metadata on an object. Quantities of objects
and parameters of those objects are low-hanging fruit in terms of exporting data to an external
database. This data is relatively easy to get and lends itself to database formatting.

In most authoring applications it is easy to fall into a trap of thinking that parameters and
quantities of objects is all you need. In fact many applications are capable of providing much
more than just raw data. Adjacency information, special relationships, connections, etc can
often be made within the authoring application much more efficiently than trying to detect these
relationships from the data in an external database.

Developing Strategies
Goals
Don’t lose sight of the end goal. The goal should not be simply to get data into a database but to
leverage that data for specific workflows. The data needed can be drastically different
depending on the workflow that needs to be supported. Goal setting should start by looking at
what data is needed by other applications. Then only the necessary data should be extracted. In

2
 Linking Your Navisworks Model to an External Database

some cases this can mean that whole objects are included or excluded from the data extracted.
In many cases though, this really determines what data on an object is extracted. If the end
result is to support automatic ordering of components such as windows in a building, a limited
amount of information such as model number and size may be required. If the workflow is
intended to support an energy performance analysis of the building, size is still required for the
window, but attributes such as material and/or thermal conductivity will be more beneficial than
the model number. As another example, energy performance models are more interested in the
thermal conductivity of a whole assembly such as a wall assembly. This is typically expressed in
a U-value that can then be applied to the overall square footage of that wall. But if the workflow
needs to support cost estimating and/or scheduling, all the components that make up the wall
assembly need to be extracted.

So far these examples relate more to how data should be extracted from Authoring applications
such as Revit, AutoCAD, etc. But data models may need to consider hierarchies of data and this
is an area where Navisworks can be leveraged better than some authoring applications. For
example, a building may have a ridged steel frame assembly consisting of ten or more pieces of
steel that are welded and/or bolted together. For those 10 pieces, it may be possible to identify
that 3 laborers are required for 20 hours and one highly skilled welder is required for 5 hours to
assemble that frame. Additionally a third trade is required to spray fireproofing on the steel and
the amount of fireproofing and the time required for one additional laborer can be calculated.
Finally, it may be known that it takes 7 working days for the whole process to be completed.
Knowing this information, it would be possible to select these 10 pieces of steel and create a
named set of these objects in Navisworks. The named set could be assigned to a schedule item
in Timeliner and then exported to an external database. That data could then be used to
calculate an overall cost for the assembly and inserted into an overall construction schedule. If
the building contains multiple assemblies that are similar this can become a very efficient way to
generate an accurate cost and/or schedule for the building.

This workflow lends itself to Navisworks because the trades involved in assembling this data are
often working in Navisworks while the trades involved in creating models are not always aware
or concerned about details of construction.

Permissions
Probably one of the most overlooked aspects of Data Management is permissions. People often
consider it a victory if they are just able to get data into or out of Authoring applications, Analysis
tools, etc. and don’t really consider the consequences of what happens when people edit that
data in one location or the other. Of course, the intention of importing and exporting data is so
that it can be used by other applications. Reading the data exported to an external database
poses no real risk. If the custom application re-imports data back in, safeguards should be in
place to insure that data loss and/or data corruption does not occur.

Controlling permissions within the database is a relatively easy task for a database
administrator. Databases are built to handle multiple levels of permission. Controlling

3
 Linking Your Navisworks Model to an External Database

permissions within Navisworks and/or Authoring applications is another story. Depending on the
levels of permissions and the types of objects, it may not be possible to completely prevent
changes by users who should not be changing the data. At a high level, some operations can be
achieved. For instance Navisworks, for the most part, does not allow users to modify and save
changes back to modeling files. This inherently controls the workflow and permissions because
users of Navisworks have read-only permission for data within the modeling files.

Even with Navisworks, data can be created and modified. In fact, the very nature of storing data
within a central database will typically mean duplicating data at some level. It is this duplication
of data that creates conflicts when multiple applications can modify the data. Which application
and/or user has permission to modify the data and write changes back to the source? How often
does this happen and how are conflicts resolved? These are all questions that need to be asked
and answered in order to successfully leverage an external database and BIM. The answers will
be much easier to identify when well defined workflows are created.

But the reality is, your best solution may very well be to create audit routines. These routines
would run at specified intervals and validate the synchronization of the data and flag
discrepancies.

Strategies
The Master Mapping Table
Modeling the built environment in more than one application will inevitably result in duplication of
data. In fact it will also result in more than one representation for each real-world object. How
can the duplication be kept to a minimum and how can these objects all be tied together to
identify that they all represent the same real world object?

My suggestion would be to implement what I call a Master Mapping Table(MMT). The Master
Mapping Table is nothing more than one database table that maps all of the various
application’s unique IDs to each other when they represent the same real-world object. This will
eliminate duplication of data within the database itself and if properly designed will minimize the
data duplication between the various applications.

When applications need to display data from the database, it is better to link directly to the
database, rather than to download data from the database and storing it locally. For example a
specification on a piece of equipment should be stored as a separate document in the database.
A custom interface can be provided which traces the ID of a selected object back to the MMT
and displays data associated with that object from the database. This could be specifications on
the object, properties from other tables in the database, etc. This could even be a type of
properties panel for the object but instead of the properties coming from the host application,
they would be coming from the database.

4
 Linking Your Navisworks Model to an External Database

Navisworks would be a terrific environment for this type of interface because it is possible to
load multiple models for a complete BIM view. Selection of any of the objects could then be
used to query data from the MMT.

Multiple Representations
Because one real-world object needs to be represented in multiple applications, we need to
build the MMT in order to track representations of the object in these applications. At some point
those objects that represent the same real-world object, will need to be identified so that they
can be properly mapped to each other. This can happen in a couple of different ways. If two
objects have already been created, then an interface will be needed in one or more authoring
applications that allow you to select the object and associate it with another object from the
database or another application. Another method would be to start with the objects created in
one application and use that as a list to create objects in another application.

No matter how the list is created, it is likely that the list will need to be validated. Validation can
happen at 3 primary levels. The first would be simply to make sure that each object in one
application has a corresponding object in the other application. This really boils down to
verifying that an object has an id in each application in which it needs to be represented.

The second level of validation would be to verify that the type of object in each application is the
correct type of object. If the id in one application is associated with a door but in the second
application the id is associated with a window, that discrepancy needs to be identified and
resolved.

The third level of validation is to compare attributes of objects. If the real-world object is a valve
and two applications represent the valve, attributes of the valve such as type(ball, check, etc.),
size and material, all need to validated.

Note that depending on the goals of the project, it may only be necessary to perform the first or
second level of validation. All three levels are not always required. The first level is required
simply to support the MMT.

Validation can happen at different times. It can happen when the real-world object is initially
assigned to an object in the model. Sometimes though it is best to just perform an occasional
audit that does validation at all the levels required.

5
 Linking Your Navisworks Model to an External Database

References
API help file:

<Install Directory>\api\net\documentation\NET API.chm

Be sure to read Developer Guide

API Examples:

<Install Directory>\api\net\examples\Tools\AppInfo

Blog

http://adndevblog.typepad.com/aec/

Forum

http://forums.autodesk.com/t5/Autodesk‐Navisworks‐API/bd‐p/600

Other Resources
When it comes to connecting to a database, there are a significant number of combinations of
data providers, databases and options. This results in literally hundreds of connection string
combinations. I find the following two websites very helpful in finding the proper connection
string.

http://www.codeproject.com/KB/database/connectionstrings.aspx

http://www.connectionstrings.com

6
 Linking Your Navisworks Model to an External Database

Review
Leveraging the “I” in BIM
We discussed the importance of the information and extracting that information to an external
database.

Developing Strategies
Then we discussed how to develop strategies. Never forget the overall goal. Identify who should
have permission to edit the data. Leverage Navisworks to manage that data.

Strategies
We discussed creating a Master Mapping Table (MMT) and validating mappings at multiple
levels.

References
Finally we reviewed some significant references to leverage the APIs needed to successfully
implement our strategies.

>>>>>>>>>>>>>>>>>>>>>>>>>>>> The End<<<<<<<<<<<<<<<<<<<<<<<<<