Cracking the USACE BIM Code

David William Edwards
Dave Edwards Consulting

The U.S. Army Corps of Engineers (USACE) is currently on a very aggressive roadmap for the adoption of Building Information Modeling (BIM) for its projects. The specific contract requirements for these projects are causing much confusion and forcing many firms to rethink their own BIM adoption. The purpose of this article is to bring to light some of these issues and how they will affect BIM purchases and workflows. I hope it’s a catalyst for starting a conversation on what changes the BIM industry must make in order to progress towards that elusive nirvana known as “interoperability.”

Even though the language in the USACE’s contracts reads as though it’s possible to use any BIM application and they claim to be “BIM neutral,” the realities are much more constrained. While some districts are allowing deliverables to be made using Autodesk products, most contracts are requiring the deliverables in Bentley BIM format. At first glance, it appears as if you can create your model in any BIM application, as long as it is IFC2x3 certified, and simply import the model into Bentley BIM to meet this requirement. However, this is where interoperability falls apart, specifically for USACE projects, and globally for the entire BIM industry.

The USACE not only requires the files to be in Bentley BIM format, they require these files to be fully compatible with the “USACE Bentley BIM v8 Workspace.” Most of us are familiar with creating 2D files that are compatible to specific layer and color schemes. Bentley's Workspaces are much more elaborate. The USACE's Bentley BIM Workspace contains thousands of directories and files. It specifies not only BIM object parameters, but CADD parameters, file directory locations, and a plethora of other “under-the-hood” system variables. The real question becomes: Can intelligent Bentley BIM objects be created with non-Bentley BIM applications and converted to match the USACE’s Workspace parameters? From all my research on this issue, the answer is “No.”

In the past, we’ve been able to convert between CADD systems by using mapping tables. But this was normally just a numerical or text reassignment. There was no consideration or need to convert object functionality and very little use of intermediate formats or industry standard designations. For instance, we converted color red which was assigned to color number one (1), and the mapping table would convert the color number to the recipient’s number designation for red. This never really addressed the issue of translating this parameter’s function. If the object parameter designation of red was really an assignment for plotting parameters, then it would have been better to translate to the parameter’s function instead of just a numerical assignment. The receiving software could then process this parameter as would be best for how it handles those particular parameters. This is the situation, only on a much larger scale, when attempting to convert from one BIM application to another.

By BIM’s very nature, older CADD-type parameters such as layers and colors are obsolete. Intelligent objects have viewing and printing parameters such as view styles, edge weights, surface patterns, and rendering parameters. These parameters are stored in the software’s default or project-specific configuration, so when an intelligent object is received via translation, all these parameters are assigned to the object as if it was created natively by the application. Parameters such as door numbers, room names, hardware types, etc., are simple text assignments which do come across with current translation methods—specifically IFC2x3 certified translations. However, a wall will come over as a wall, but it will not have the same exact parameters as if it was drawn natively. On one BIM system, a wall may be called “Basic Wall: Interior – 5in Partition (2-hr)” and that same wall on another system may be called “C1010: STUD 5 – Two Hour.” In this case, a simple mapping table to convert the wall style names would work for one object type to be converted to the matching one on the other BIM application. However, this type of mapping only works if the sending and receiving applications know what name is given to the same wall system. In the future, it may be necessary to create a standardized system for coding material types. This way, it would be easier for applications to know what components are contained in the translation files and how best to represent them. The receiving system would not only check the material components of an object it receives, it could match it to its own style or create a new style on the fly.  

I can certainly understand the USACE’s position—needing 100% compatible files in the application they have chosen as their BIM solution. But since no workable translation process currently exists, many AEC firms have come to the hard realization that if they’re going to bid on USACE projects, they must do 100% of their work in Bentley BIM applications. They must also work with consultants which produce 100% of their work in Bentley BIM. This is causing many firms to move completely to Bentley as their BIM solution or become BIM “schizophrenic.” A third option is to not work on USACE projects until this requirement is changed or an approved translation method is created. Many AEC firms are being forced into a single application solution, which may prove to be detrimental to BIM’s future growth.

For many contracts, the USACE is requiring a single source because the BIM industry is still in its infancy and the conversion procedures long established in the CADD industry are not available. In recent years, we’ve seen some amazing “cooperation” between competing firms and hopefully this will continue for the BIM industry. We also have the incredible work being done by the International Alliance for Interoperability on the IFC format. However, it will also take the concerted effort of BIM vendors and users to make BIM interoperability a reality.

On the application side, vendors have to understand that just having the best products and a certification is not enough if users get shut out of working on specific projects. They need to take advantage of the open nature of translations like IFC and create custom files specifically designed to maintain the parameter needs of a particular recipient application. They need to create their own object parameters in such a way as to properly process standard translation files. They also need to provide tools for these translation files which will allow users to better control the process. Vendors should also allow users to know exactly how parameters of objects are assigned so that automated processes could be developed to meet client requirements.

On the client’s side, BIM deliverables should not be required to be created in such a way that only one vendor’s application can create them. They should want the best possible product, which often comes from a variety of users deploying a variety of applications—the best tool for the job. This involves simplifying as much as possible the nature of the required deliverables, with emphasis on making them as friendly as possible towards as many applications as possible, or at least detailing the required specification so that vendors and users know exactly what’s required.

I know from my consulting experience that because of the hype and confusion, the term “BIM” is becoming a very sore spot for many AEC firms. Single source requirements are unfortunately bringing to the forefront many of the industry’s weaknesses much too early in the game. Users are also feeling as if they are being sold products that perform beautifully in a vacuum, but the real world requirements of data interchange between disciplines and applications are causing BIM adoption to come to an abrupt halt. After spending enormous amounts of money on new software, new hardware, new personnel, and new training, firms are finding out that what they’ve been sold won’t work. We know BIM is where the industry is headed, but we’re finding out that it’s arriving there before all the pieces are in place for it to be workable and profitable enough to supplant current solutions.

Most of all, we must realize that this is a very radical change to one of the world’s largest and oldest industries. Small steps need to be taken before too much is set in stone that will constrain growth and advancement in the future. I hope this article has at least opened the paths for communication and a better understanding of some of the challenges that lie ahead.

On second thought, maybe BIM is just too complicated for true interoperability to be achieved. What exactly is a “wall”?

About the Author

David William Edwards has been in the CAD industry for 25 years as a manager, consultant, author, lecturer, and font developer. He is currently specializing in 3D Architectural Renderings, BIM deployment/integration, and custom font services. He has created a new standard CAD font known as "Project Newplex" (see www.tcfonts.com). He is also a professional drummer and voice over artist. He can be reached at: dave@tcfonts.com.

Note: The views expressed in Viewpoint articles are those of the individual authors and do not necessarily reflect those of AECbytes. Also, AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.

Viewpoints > Issue #44 > Printer-friendly format