Making Sense of Data Interoperability in the BIM World
It’s good to be teaching again at Autodesk University. The past several years have seen some pretty considerable growth in the AEC industry and, in some cases, growth in a pretty convoluted way. As I’ve gotten into my second year of my firm’s BIM implementation, I’ve started trying to look beyond just the simple construction documentation process. By the way, maybe you have figured out that plain AutoCAD® versus AutoCAD® Architecture/MEP versus Autodesk® Revit®, is, to quote one of my engineers, “really different from drafting.”
At my firm, the “look” we’ve been taking is the basis of a class named “You did WHAT? AutoCAD, Revit MEP and AutoCAD P&ID? Amazing!” at this year’s AU. Yes, this is my shameless plug.
One of my big tasks has been to integrate a consistent set of parameters into our entire library so we could get better scheduling results. We’ve also begun the implementation of AutoCAD P&ID for our instrumentation documents. Being the “BIM” guy, I surmised that there had to be a way to tie data from these two applications together, even if Autodesk wasn’t directly doing it.
This got me thinking about interoperability between the wide seas of products Autodesk carries. How many of you have ever heard of an initiative at Autodesk called AIRMAX? It came out a few years ago and was intended to be the program where AutoCAD (include AutoCAD-based applications such as Civil 3D®), Inventor® and Revit, along with Autodesk® 3D Studio Max, were all tweaked to make them work better together.
So far, we’re already seeing progress in this arena, starting with the implementation of the ribbon interface – love it or hate it, having a common interface does make things easier for users who are constantly working with multiple applications at once. In realty, that’s what many engineers do—they work in AutoCAD, Revit, Inventor, Excel, Word. Anything that can make it easier for a user to find tools is a good thing.
Sharing files is also a part of this strategy. The role of the .ADSK file was to have a common format that all applications could use to share parts with other applications. While this hasn’t been widely adopted, having a common file format does have its advantages. We’ll keep an eye on this for later versions.
But when we, in the engineering and architect design firm, talk about interoperability, it’s the data that gets us worked up. In the early days of computer-based engineering applications, we saw a crop of high-dollar, high-maintenance applications such PDS, PDMS, and others on the market. The big selling point was the link between the data in the model and the CAD files that were used to build the facility. For large industrial manufacturers, having the data associated with the part was mission critical—especially if you have to deal with compliance regulations. That’s what many of the industry’s long-term engineers think—that you really must have those expensive, high-end packages to do this work, which takes a lot more time to produce. So when you start to talk to them about it, their collective budget spreadsheets cringe in abject fear.
This has been a market that Autodesk is really just starting to play in. Its first foray with AutoCAD P&D and Plant 3D represented a good example of these first steps. But as a Revit user primarily, I find myself in a quandary. I didn’t really want this product based on AutoCAD for a variety of reasons. One big one is that we’ve bought into the sales pitch that a single, integrated model is the way to go. It’s not just because producing construction documents, extracting plan, elevation, section, and schedule views from a single model is vastly faster, it’s just more efficient than producing those views individually, as we’ve done in AutoCAD for years.
One of our primary points of logic was the data associated with the object—electrical, mechanical, identity data along with construction sequencing, cost, and maintenance—starting from a single source. The problem is that Autodesk hasn’t really had a good way to do this for the everyday user or layman like myself…yet (hint, hint – are you listening?).
Here’s what is currently on the table. From AutoCAD, you can import and export to Excel tables with little to no problem. This works great with base AutoCAD, but is lacking on the AutoCAD-based BIM applications such AutoCAD Architecture and AutoCAD MEP. You can export with no issues, but the schedule has to be converted to a plain AutoCAD table to be bidirectional, which defeats the purpose of the schedule itself. Excel itself has limitations when comes to the amount of data. However, dbConnect is a tool that adds more juice to the AutoCAD-based tables, since they allow a direct connection to a SQL database. So if you’ve completed what you need to do in the AutoCAD MEP project, then you could convert to a plain AutoCAD table.
One really nice thing about AutoCAD P&ID is the automatic association to a SQL Database, in both the form of a local, “lite” database that gets its data strictly from what you add to the project class properties. You can also set up to SQL Express, which I’ll talk more about in a minute.
Even if you never use the actual SQL database, AutoCAD P&ID has a nice data manager for tracking all of the information in the project. It also has a nice import/export utility for Excel. This is important to us, as all of our engineers are proficient at Excel and are comfortable working with it.
In Revit, it’s not quite as easy. There’s no native Excel Import/Export utility, other than the ability to save a schedule as a CSV file, with the only round trip available as a one-way trip back through AutoCAD. There are some aftermarket products, such as Ideate’s BIM Link, the upper end of the price scale, to CTC’s Excel Link, a lower cost, but limited-feature solution. Both do a great job of importing and exporting data to Excel, but after reviewing both and doing a little cost analysis, we decided to develop our own .XLSX import/export utility that gives us more flexibility on the types of data and methods used to share information. That covers basic information, but there’s still a lot of behind-the-scenes work to be done before it works. This includes setting up a primary equipment spreadsheet, defining OLE Links between the files, and making sure the data formatting doesn’t cause Revit or AutoCAD P&ID grief.
The next logical step was to spend a little time with Revit DB Link. Available to subscription users, this utility is supposed to allow a user to create a connection to a SQL database directly, and create a bidirectional link. At first blush, it’s seems pretty simple, but then there’s the rub—it’s not. From a layman’s standpoint, you’d better have a couple things straight. Setting up a SQL database is not simple, and getting the links defined correctly can be maddening.
And that’s the gist of this conversation. This workflow, still in its infancy, needs to be clearly laid out, so the users and companies have a clear picture of the required effort needed to incorporate these tools.
So, let’s take a brief look at my feeble attempts to get Revit linked to a SQL server, where the data can be cleanly shared with other applications such as AutoCAD P&ID. The first step is to understand how SQL works. There are two types of servers—local and networked. Local is the easy one and is what AutoCAD P&ID uses by default. If your company is large enough and you have projects where multiple users may need to access the same data, then purchasing the full license of SQL Server from Microsoft may be the way to go.
SQL Server Express, the free version (which is also directly supported by AutoCAD P&ID), has to be installed on your computer to get Revit DB Link to work, prior to creating a link to any database. Microsoft has three primary versions you can work with—2005, 2008, and now, 2012. There are older versions, but the 2008 R2 release is the most common. The installation can be tricky. I had to go through more twists and turns such as fixing registry errors that caused the installer to fail and resolving compatibility errors. Once the server portion is installed, you also need to install the SQL Server Management Studio console. This tool is what’s used to define your local database. One tip: make sure you use Windows Authentication for passwords and access, and do not use separate SQL administrator logins—that results in a lot more effort to get access to the data.
Once the server database is defined as a named instance on your local hard drive, you can start Revit DB Link. In the application, you establish a link to your SQL database. Revit runs through an initial export. Once this is complete, you can use the edit and import features to review the data. One item I noticed right out of the box is that all data doesn’t automatically flow from the project to the database, such as custom shared parameters. But our main issue with the application is the inability to control what data is exported.
Without having the control over the data, we needed to look somewhere else (which is the topic for a particular class…coming up in Las Vegas in a couple weeks).
Wrapping up this preview, I did a little research to see who else is looking at leveraging the data in the Revit model with external databases. Depending on your need, there’s a few out there dipping their toes in the water (and in some cases, diving right in). Archibus (www.archibus.com), a long-time Autodesk developer, has a nice little plug in that runs directly inside of Revit and allows it to query data from the model (or models) into a common database that is used for facilities management, asset management and inventories. More recently, IBM’s Maximo asset management software (www.ibm.com) has been working with the Autodesk Labs folks to incorporate their version of database query and management from the BIM model, with uses from construction to lifecycle management.
One of the more interesting sites I reviewed was from Mario Guttman, the owner of Whitefeet (www.whitefeet.com). Beyond just being the site for a laid-back cat, this site includes information and trial versions of an FM Link application that exploits the data that can be exported via SQL.
There are also many great resources you can follow to learn more about database integration with Revit. Jeremy Tammik with The Building Coder (thebuildingcoder.typepad.com) writes an excellent blog about Revit API programming and database integration. He has the best behind-the-scenes look available from the Autodesk camp.
Does this leave you with a little insight? Getting into the databases of Revit and AutoCAD is possible, but we still have a long way to go. If you want more of this, make your voice known to Autodesk. This is one area of wide-open growth that represents a great untapped market. And the sooner the better… know what I mean?
David Butts is the BIM Specialist for the MEP and Process engineering projects for Gannett Fleming. Based in Raleigh, NC, he has 27 years of experience with Autodesk products, starting with AutoCAD and extending to the Building Design and Plant Design Suites. He is a regular speaker at Autodesk University for AutoCAD MEP and Revit MEP products. Prior to Gannett Fleming, he spent 13 years in the Autodesk reseller channel as an MEP consultant and training manager.
