Preface:
I decided to add a new category to the blog for CAD. A year ago, the thought might have nauseated me. But having become self-employed and dependant on the software (as a contract drafter), I’ve come to see it in a new light. It’s no longer something I immerse in for 8 hours a day, $20 bucks an hour. These days, my ability to utilize every function and push the envelope of my particular software (AutoCAD) translates directly into dollar amounts.
So, as you can imagine, I think about it quite a bit. And amazingly, some of the thoughts actually seem interesting enough to put down in a blog. 
AutoCAD and the Current Drafting Paradigm
“Back in the day” – Architects/Civils/Mechanicals/Structurals/Etc obviously drew their plans by hand. I think that was the late Cretaceous period… maybe a little earlier. Regardless, eventually computers came along. I don’t know who came first – but obviously (to drafting geeks), AutoDesk creamed the market. AutoDesk reigns supreme. You can buy a reeeeally nice car for what AutoCAD charges to license a company of say… 10 people, with AutoCAD and a couple add-on packages for each seat.
Sorry, got distracted.
WHEN computers came along, the drafting industry shifted to CAD in a logical, but inefficient way. Instead of utilizing the computer’s data organization capabilities, software firms simply shifted drawing on paper to drawing on a computer. In a way, they probably had no choice. If they (software firms) had radically changed the way companies produced their plans, it would have taken far longer for engineers to adopt/adapt. Whatever the reason, two… three decades later, we still use the software as glorified paper and pencils.
The first problem with this model is that – all of the information in a set of plans is represented graphically. The problem with representing data graphically is that graphic data is not immediately recognizable. It is fuzzy. You can’t look at a sewer pipe sitting there - drawn on the screen - and know “Why, that pipe has an incoming invert of 120.34 and an outgoing invert of 122.43! It’s flowing the wrong way!”
You have to measure it, label it, add notes, dimensions, etc. So you’ve got a label on the pipe – Nooooooooooooo! Duplicate information! Duplicate information is the evil of any data-driven system. It wastes memory and time, and when it comes to updating… I’m going to estimate that 80% of the errors I see on plans result from some piece of information being missed during an update - caught on pages C3.5 and C7.8, but whoops… someone missed it on page C9.39.
“How is the information duplicated” you ask? Well, you’ve got your line – which has an exact length, and (assuming it was done in 3D) exact invert elevations. The rest of the data can be derived from that. But you’ve also got your label – a textual representation of the same data.
Here and there the software attempts to keep that data in sync. For example, in AutoCAD, dimensions can maintain association. Move the line, and the dim comes with it, automagically updating. Civil3D actually takes the concept much further. Tweak an alignment, and entire profiles update in real time.
But overall, the system is still massively graphically oriented. AutoDesk’s work (and others, I’m sure) represents a combination of two paradigms – a compromise between the old system and the alternative system. A necessary compromise, no doubt. Even with Civil3D’s familiar environment, it’s still been slow to take off.
Those stubborn engineers.
So what IS the alternative system?
As usual, AutoDesk has taken the most prominent stab at it. It’s called building information modeling (BIM) in the architectural context, and AutoDesk’s Revit apparently takes a non-graphical approach to developing plans. I haven’t played with it yet… but, whether Revit or some other system, the industry is movin’ that way, so we’re all going to jump on the bandwagon sooner or later.
AutoDesk aside (THEY’RE EVERYWHERE!!!1111), what is BIM?
1. It’s the way things should be.
2. It’s fundamental premise is:
Plan data must be represented in cold, hard form that is not open to fuzzy interpretation, and relationships between the data must be defined. That means – you should be able to represent an entire design in a relational database, where the data is in unforgivingly well defined form, and relationships between various elements of that data are defined and rigidly adhered to. The important part – the graphics must be derived from the data, not the vice-versa.
That’s a mouthful – so here’s an example.
Say you have a square building in plan view. You grab a corner of the building via a grip, just like in AutoCAD, and give it a stretch, lengthening one of the walls. The way things are usually done now, this will simply stretch that one corner of the building, and obviously, your square now has two corners that are no longer 90 degree angles. The way it would be handled in a BIM system:
You’d stretch that wall. The graphical representation of the object would communicate with the underlying database: “my length has increased by 10′”. The database would update that value. Next, the database would go through all of the relationships connected to that wall. It would find that a relationship has been defined by the designer, that the opposite wall is to be the same length as the current wall. It would update the length of the opposing wall to be the same as the stretched wall.
But wait! That’s not the end! This is just plan view. Because of our no-duplication rule, all associated elevations, sections and details are all referencing the same data. So you stretch that one wall – and WHAM! The entire plan-set updates itself. Perfectly. No errors. Not even on lonley page C9.39.
Sweet. So what’s the point of this article?
Whether due to affordability, stubborn engineering minds, (reasonable) caution in adopting new technologies, or inter-industry file compatibility issues, BIM (or… I dunno… how about SIM – “site information modeling” for civils) is proving slow to take hold. HOWEVER! Partial solutions are available, and can be incorporated directly into existing systems. At least in AutoCAD, which, at this point, is all I can talk about from personal experience.
The most basic support, which has been around for pretty much ever, is external references – aka xref’s. These are simply live links between multiple files. Update the design file, and all sheets that reference the design file will update. For the most part, xref’s are horribly abused, used inappropriately, used without well thought-out schemes, etc. But used properly, they can play a huge part in minimizing data duplication.
Also basic is – viewports, and the associated layer control provided per viewport. The downside of viewports is the scale/text size complexities they introduce. Those complexities can mitigated with excruciatingly well organized text styles and … erm… a large brain.
More advanced, an exciting introduction to AutoCAD is dynamic blocks and attribute extraction. Dynamic blocks allow you create parametric “smart” objects, and attribute extraction allows you to view information embedded in blocks (traditional or dynamic) in a myriad of ways. A simple example of the power of these two combined can be seen in the keynote system download(opens in a new window) on this site. Not included in that example is the Dynamic Block’s ability to be data-driven via a small, self-contained database-like function called a “lookup table.”
Advanced to the point of near-inaccessibility (and used by probably 1% of the industry), you have database links and VBA support, which together can do amazing things… as long as you have a true geek on your team to write some custom software.
Anyway, I would like to do some “Best Practice” articles on xrefs, file organization, etc. But since I never finish things that I start, or follow up when I say I want to do something, who knows?
Check back in a week.
