People wave their hands and talk about BIM, CIM, model-based software, and model-based design. What do these often used buzz words truly mean to civil engineers and surveyors?
Where does the rubber hit the road in our daily grind?
Maybe the answer is simple. Maybe not so much.
Model-Based is Simple and Elegant
It sure appears to take a while for people to discover the unexpected consequences.
We build a reasonably realistic model of what we want before we attempt to construct it. From my perspective the phrase "reasonably realistic" means suitable. Suitable is probably a good subject for another post. Suitable is probably as important as those precision and accuracy words we tend to employ when we talk about software and engineering.
Hopefully, our Civil 3D model building isn't too man-hour intensive. At first, learning the model-based structures and processes (workflows) unquestionably make our model building consume more project man-hours up front.
If that man-hour cost doesn't reduce quickly, you are probably doing some basic things "wrong" or at least not too efficiently.
If it keeps happening, please get some help. You need a change of perspective.
Civil 3D is really not supposed to be or work that way.
The Civil 3D Money Pit
Sad to say…Civil 3D doesn’t ship with anything like the robust Styles and resources you need to do actually do real world model building. Our Framework for Civil 3D production products do fix that.
Hopefully, our model is good enough and the design software is also robust enough to actually help us construct, quality check, and publish the model in multiple ways as well.
All three parts are essential and mutually significant to our real world project success and profitability.
All of the following are put to the test throughout these Build, QAQC, and Publish processes:
- Our personal and corporate skill and experience
- Our understanding of the design discipline(s) standards and real world systems
- Our Civil 3D usage skills both personal and corporate
More is Not a Joke
The problem of multiple core production processes changing at the same time isn't a joke. Simultaneous multiple processes upset our old school CAD workflows. Most of all, they challenge our habitual way of working - what always worked before.
Personal task accountabilities get all mashed up and mixed together into new, and perhaps, unforeseen ways in the new environment.
The basic questions and answers to What, Where, When, and How simply are not the same anymore.
Those uncomfortable and overwhelming facts can and do produce bad results and negative expectations.
We really didn't want everything to change at once in the first place. But it did, it will, and it must. Complex socio-economic realities we don't and cannot control make that so.
We Can and Do Miss the Forest for the Trees
At the beating heart of model-based design is the core concept that an iteratively-built model and the managed data behind will produce the published results we will require.
Yippee! The end of civil engineering and survey drudgery is on site!
Civil 3D actually can do this remarkably well today. But on a practical level, to many Civil 3D users and organizations it sometimes feels like Elvis left the building or never showed up at all.
The model building and publishing problem and the complexity of the output publishing processes can easily become a beast all by itself in these multi-process muddied waters.
Here's why.
Our decades of previous CAD experience teach us to go back and focus all the time on the details present in the CAD model to solve the problem. That makes sense because this focus was absolutely necessary when the CAD software was primitive-based NOT Feature and fundamentally data-based.
Put another way...
We won't and can't throw away our previous "investments" in Civil 3D CAD standards even when they may no longer apply or require some additional investment to again become even more useful.
All the time I hear the telling examples of this kind thinking.
"All our details are in CTB format so we can't use STB or we have to convert them all.”
They employ old school .shx font files in the details; have their own internal detail Layer scheme; historic hatch patterns, etc.
Who doesn't?
Converting all that to the any other standards will "take forever" and be a waste of resources that are currently (can I say always) in short supply.
“We employ an XREF-based basemap in all of our projects. We need that method to work in Civil 3D to publish our plan sets.”
"We'll have to keep doings things the same way."
Huh?
Aside from the fact that there are a number of ways to automate and/or systematize a conversion process for the CTB to STB conversion stuff, (They do own AutoCAD Map 3D and AutoCAD after all) there is another significant issue perhaps best exemplified in the basemap example above.
Ask That Other Question
"What are you publishing? Are you really handing over digital drawings, your complete project models (Yes there can be more than one), submitting a dwg based plan set, or something else?"
To these folks their "project", the "drawings", the "model", and even their deliverables are all the same thing. To be honest, they probably DO know better, but the CAD habit has been their world since who knows when.
They know Civil 3D is different, but they still can't quite break the old mold and reengineer the new machine they need.
At some deep mental and mindset level Civil 3D just replaces AutoCAD. Sort of.
To change how and what they produce as work isn't being questioned in any real depth by anyone. Ok. Maybe some of their customers are shouting. Are those folks just tired of converting the dwgs to get backgrounds to use in their own deliverable plan sets.
Maybe live publishing the XREF basemap is a performance hog that negatively extends project deadlines in the worst case scenario.
The Critical Path Issue and our focus must be
Make Publish on Demand Real
The model is the Model. That is all it is.
Good models don't and shouldn't care what they look like in a Feature-based (data behind) world. The model and its data structure(s) should be stable, but remain malleable, flexible, and able to be validated first and foremost. Civil 3D is not perfect at this without some informed user hand-holding, a known project|data structure, and some organizational maintenance and publishing processes in place.
Recall that old school CAD was pitched as though it could do Publish on Demand too. Software vendors promised that (and even continue to promise it today). Technically, CAD by itself could NOT perform because of its graphic CAD primitive only definitions that are built into it by design. A model with rules, consistent behaviors, and managed interactivity matters.
“CAD is like stacking concrete blocks on the ground and saying or thinking you've constructed a retaining wall.”
Ordered pictures of parts by themselves do not make systems. However, the old school CAD device did allow us to create an acceptable illusion of the real world system(s).
Please note that you have to both manage and work on the PARTS and their careful arrangement in detail to make the end published CAD illusion work.
Is it still called "AutoCAD" Civil 3D for a reason?
NOT
We know Civil 3D employs Feature (model-based) Style representations to display and annotate the data behind buried in a Model's Features. Yes, if you explode the Civil 3D Features you'll get simple ACAD primitives. Dumbing down to CAD into any format is not rocket science today, but that is only practically useful if you view the acts as a linear publishing or one-way output process. That means that the Export to process REALLY is a separate and discrete process triggered by a known event (a benchmark) and performed from a known checklist.
All forms publish and reporting processes in Civil 3D need to be seen and dealt with this way. This mindset maximizes the use of your resources to do this. The more you can move and concentrate publish details into a one-way OUTPUT process the faster it works, the easier it is to maintain, and the cheaper it becomes to perform. That is basic process engineering and mechanics 101.
Work the Same and Publish on Demand or NOT
Intelligent Publish on Demand (iPOD) is something you must work on ALL the time in your project. You will and MUST fail at that to learn and improve to get better at it. This is iterative engineering.
How Do You Do That?
The specifics and details of the output iPOD process must NOT get mixed up with the model building, QA process, etc either. This is HARD to do because of our detail-centric CAD experience is focused on what we see NOW. In other words - the CURRENT state of MY drawing.
The Civil 3D software doesn’t demand a project. It is a project.
STOP
In a model-based world, ALL publishing ALWAYS happens from an OUTPUT drawing specifically built and designed to help us perform the specifics of our Publish On Demand process. There is no magic button so I put Intelligent up front. Our brains must be engaged for us to be successful.
That means there WILL be more than one Publish On Demand drawing doesn't it? A multiplicity of template resources is probably in order too.
Our MODEL should eventually become the replaceable and almost disposable object in our project structures.
Read that sentence again.
This is the TEST.
Do your Civil 3D projects work like that?
That is what "Model-Based", "Feature-based", and/or "Data-based" really means in practical terms.
BIM IT
Now if we want to talk about BIM in a substantive way, we must introduce continuous feedback loops into those external publish processes too. We must have those basic loop structures and methods already in our internal processes to get to functional Publish on Demand and do our internal QA well anyway.
Flip the Mindset
Real world BIM is all about the suitable quality of the information published.
The architect, the contractor, and the owner all really do need different things.
Can you say, "How would you like your Surface, Alignment, Parcels, etc. today?"
The Framework’s Jump Kit product exists to help you focus on that More Important Work.
That happens to be what you get paid for. You should be able to get paid for more.
Release the Power Beyond the Code
Get the Framework for Civil 3D Release 8
This post is in the third iteration. Did it 10 years ago. Did it 5 years ago. Time and software seem to change. The fundamental human problems stick around unless we proactively learn from the past.