Structural engineers using BIM today have a lot of items on their wish list. High on that list for most of them—if not at the very top—is a unified model for documentation and design.
That kind of consolidated workflow is more possible every day, but there are still some significant challenges to overcome along the way.
Here are some key insights on BIMinteroperability, and the things to consider when attempting to integrate design, documentation, and analysis.
What Do We Gain? Why would you want to integrate your structural design and documentation models anyway? This is the easiest question to answer: Integration reduces redundancy.
If you can change a beam size as the result of a design computation and have it automatically update in all the plans and details where it appears, you’ve just saved yourself time and effort. Not only that, but you’ve reduced the risk that the new size will get transferred incorrectly when someone enters the new value by hand.
How Does the Communication Work? When deciding which programs to use for structural analysis and documentation, a lot of factors come into play. Each program has a unique set of strengths and weaknesses, even before you get to how they talk to each other. Interoperability with BIM software might actually be pretty far down on your list of decision factors.
For engineering design, the technical capabilities come first. One program might be best for concrete design, another one for steel. Or a program might be good at analyzing lateral forces, while yet another can handle composite floor design. Your company might have a license for a certain program, but not all—a non-technical, yet realistic, consideration.
Once you get down to interoperability, a new set of factors comes into play. First, what element types are able to go between the BIM software and the design program? Different translators can handle different things, some better than others. For example, foundation elements are not supported in all workflows.
 |
| Image Courtesy : Odeh Engineers, Inc. |
Second, even if an element can be transferred, do you want to? Floors are sometimes better off being re-created in the other program.
Third, what element data does each program read when creating the link between models? Some programs differentiate between analytical and physical data, and it’s important to know which values are being used.
Another thing to understand about the connection workflow is what file types are involved, and what plug-ins or external programs are provided or required. Some programs can make their files talk directly to each other, while others require an export/import through an intermediate file.
You’ll need to understand which software programs need what processes. And you should also take the time to study the manuals and tutorials to learn the quirks and nuances of the different translations. (Support contracts also come in handy here, in case you get stuck.)
What If the Two Models Need Different Things? Once you get past the technical challenges, the last remaining hurdle is the different (sometimes conflicting) requirements of analytical and documentation models. Much of the time, the differences boil down to the level of precision required for documentation versus the approximations that are acceptable in analytical software.
As an example, consider open-web steel joists. Their construction typically requires that the top of joist is 2.5 inches or 5 inches above the top of the steel beam supporting it. This offset is critical for proper detailing of that steel connection. However, from the analysis software’s point of view, those elements exist in the same plane.
Another example is edge-of-slab conditions. A few inches of cantilever on a concrete slab on a metal deck might not be a critical factor when designing the slab, but it’s definitely important in the construction documents.
It’s not just detailing that can cause these conflicts. Let’s say that the original schematic design for a building laid out the columns on an 18-foot grid spacing. It stays that way for a few weeks, until some constraint requires a single bay to change to 18 feet, 2 inches. Now what? The engineer knows that the 2-inch shift doesn’t affect the beam sizes, but the documents definitely need to be updated.
What does that do to the link between the two models? You have a few choices: 1) Take the time to update the analysis model anyway; 2) Temporarily fix the documentation model and make a note to update the analysis model later; or 3) Break the link and continue with two separate models. Option 1 is clearly ideal, but unfortunately it is often abandoned due to limitations on time and resources. If you end up with option 2 or 3…well, hopefully at least you got a one-way transfer out of it. Even small steps are progress.
Where Do We Go From Here? None of this is meant to discourage you from attempting to integrate your analysis and documentation models. Interoperability technology is getting better every day, and many of the concerns raised here may be reduced or eliminated in the near future. In the meantime, though, it’s best to be informed about the pros and cons of combining documentation and design, so you can be prepared for what you can accomplish today and what will be possible tomorrow.
Author: Kate Morrical
Image Courtesy: lineshapespace.com
~~~~~~~~~~~~~~~~~~
Published By
Rajib Dey
~~~~~~~~~~~~~~~~~~
No comments:
Post a Comment