# Model-Based Definition in Non-Standard Automation Projects
Engineering drawings are losing their monopoly. In a growing number of non-standard automation projects, the 3D model carries the geometry and the drawing is a contract that talks about everything else. Model-based definition (MBD) moves the dimensions, tolerances, notes, and product data into the model itself, making the 3D model the single source of truth. For one-off machines built by small teams and fabricated by subcontractors, MBD done pragmatically is a serious time-saver; done dogmatically, it is a way to stall a project while everyone argues about the file format. This article explains where MBD genuinely helps, where it hurts, and how to adopt it without losing the delivery.
What MBD Actually Changes
In a conventional workflow the model is geometry and the drawing is authority. Dimensions, tolerances, finish, and notes all live on a 2D sheet that must be created, revised, and cross-checked against the model. MBD stores geometry plus that same product information as annotations directly on the 3D model. The recipient of the model — the machinist, the fabricator, the inspector — opens the same file the designer edited, reads the tolerances at the feature, and works from one source rather than two. The change management problem shrinks because there is no drawing to forget to update.
The shift is most honest where the 2D drawing was always a pale shadow of the model anyway: complex weldments, sheet metal parts, and assemblies where the 2D view could never capture the intent. For those, the drawing was a translation loss, and MBD removes the translation. For simple turned parts and profiles, a quick 2D view may still be the cheapest way to communicate, and MBD’s advantage shrinks. The judgment call is which parts gain from model-centric definition and which still want a paper sheet.
The Delivery Contract Still Exists
The machine shop subcontracting your weldments is not necessarily equipped to read annotated models, and the plate supplier certainly is not. The pragmatic adoption of MBD is not “no drawings ever”; it is “the model is the authority, and the drawing is a generated view of it.” Quality documentation, inspection reports, and PPAP-style records usually still want a 2D presentation even when the 3D carries the data. The deliverable the customer’s QA department files may legally be a print. Plan the delivery contract around your real audience before committing to model-only release.
The same pragmatism governs your own suppliers. Survey which fabricators and machinists can consume MBD directly, and which still need a drawing they can hold. A delivery strategy that sends annotated models to the suppliers who use them, and views to the rest, captures most of the benefit with none of the blocked orders. The cost of the dual approach is small when the views are generated from the model rather than drawn by hand.
Annotations That Travel
MBD’s promise depends on annotations that survive the file’s journey. A tolerance noted on the model is only useful if the recipient’s software shows it in context, and if the model format carries the semantic load rather than just the geometry. The common exchange formats differ in how much annotation they preserve. A native model carries everything; a neutral exchange format may carry geometry without its annotations, silently demoting your MBD to a dumb solid. Verify what your exchange partners actually receive before publishing the model as the contract.
The discipline also applies inside the model. Annotate the datum scheme, the critical tolerances, and the finish notes at the feature they describe, and keep the presentation states organised so a recipient can turn on exactly the views they need. A model stuffed with overlay on overlay defeats MBD’s purpose by recreating the worst of 2D clutter. The best MBD presentation is sparse: the datum scheme visible, the critical dimensions shown, the non-critical geometry uncluttered.
Change Management With a Single Source
The cleanest win in MBD is revision control. In the drawing-based workflow, a design change risks the model, the drawing, and the BOM diverging across the week it takes to propagate. In MBD, the change lives in the model, and every view generated from it regenerates in sync. The change note, the revision, and the affected features can live in the model’s metadata. The memory of why a dimension moved survives in the file where the next engineer will look for it, instead of in an email thread nobody can search.
But a single source of truth is only single if everyone actually uses it. The practical failure mode is the user who exports the model to a neutral format and starts editing there, creating a new source. MBD change discipline needs the same rules as any configuration management: one authoritative file, controlled access, and a documented revision process. The tool does not deliver the discipline; the process does.
Inspection: The Reading End
A model-based definition is only as strong as its readership in quality. The inspector who cannot extract the tolerance from the model will write it down somewhere else, and that somewhere else becomes a second source of truth. Measurement programs generated directly from the model (for CMM or digital inspection) remove the extraction step entirely, which is MBD’s strongest payoff: the nominal geometry and the tolerance drive the inspection program with no transcription error. For simple caliper inspection, a generated 2D snapshot with the tolerance visible is still the practical readout.
The inspection strategy should be decided when the MBD annotation plan is written, not after parts arrive in quality. Call out which features are critical enough to inspect, which tolerance governs them, and how the inspection reads from the model. When the design, the fabrication, and the inspection all read the same annotations, the quality loop closes without a stack of drawings being translated by hand at three different desks.
MBD in Welded Assemblies
Weldments are MBD’s natural habitat. A weld symbol, a callout for the preparation, and the datum faces annotated directly on the 3D weldment communicate the welding intent better than a 2D view ever did, because the welder sees the joint in the orientation they will actually build it. The MBD weldment also carries the machining stage: which faces are post-weld machined datums, which regions must be kept clear of weld, and the final envelope for the machining operation. The single model holding both the weld state and the machined state is a genuine improvement over a drawing set that struggles to show either state well.
The same model should carry the assembly context. Include the fastening scheme and the interface datums so the weldment arrives at final assembly already aligned with its neighbours. MBD in weldments crosses the boundary between fabrication drawing and assembly model, and when both live in the same file the handoff between the fabricator and the fitter stops losing information.
Pragmatic Adoption Path
- Identify the parts where the 2D drawing is a genuine loss (weldments, sheet, complex assemblies) and start there
- Confirm the exchange format your suppliers and inspector can actually read
- Generate inspection views and drawings from the model, not by hand
- Standardise the annotation presentation states
- Keep one authoritative model file and a documented revision process
The Paper Drawings That Still Matter
Even in a mature MBD workflow, a few paper drawings carry roles the model does not easily replace. The structural fit-out and the safety rulf-fence certification file may legally demand a signed 2D presentation, and the field service technician swapping a part five years later may open the manual’s drawing rather than a CAD station. The pragmatic answer is to generate these views from the model, with the same revision and the same datum scheme, so the paper is a faithful projection of the digital truth rather than a parallel document that can drift. The paper that agrees with the model costs nothing to maintain; the paper that disagrees costs a customer.
The same projection discipline applies to the customer’s own documentation. Their maintenance manual and spare parts list are built from the machine’s documentation package. If that package is generated from the model, the spare part callouts, the inspection references, and the assembly instructions all stay in agreement with the delivered geometry. MBD’s real win is that the entire documentation family is generated from one source and cannot drift from it.
Adding and Enforcing the Metadata
An annotated model is only as useful as its metadata is complete. The part number, the revision, the material, the finish, the mass, the drawing reference, and the owner belong in the model’s properties, filled by the design, and read by the downstream systems. The BOM that draws its part numbers and descriptions from the model metadata is a BOM that can never disagree with the geometry. Enforce the metadata at the template level: make the required fields part of the part creation, and validate them at release, so a design cannot leave the office half-identified.
The metadata also carries the change story. The revision history, the change notes, and the approval dates in the model’s properties replace the drawing title-block archaeology that used to recover why a dimension moved. A model whose metadata is kept current is a model whose history is a readable record; a model whose properties were ignored is a mystery the next engineer will spend a day unpicking.
The Legal and Contractual Frame
Model-based delivery sits inside a legal frame that still runs on paper signatures. The contract may accept the 3D model as the definitive geometry, or it may demand a signed drawing as the acceptance basis; the question is settled by the agreement, not by the CAD trend. Before committing to MBD delivery, confirm with the customer’s procurement and their QA what their incoming inspection and their acceptance records require. The modelling choice should follow the contract, and the contract should be written to describe what actually ships.
The same clarity governs subcontract fabrication. A fabricator who accepts the model as the build basis should sign an agreement that the model is the living geometry and the generated views are projections of it. The fabricator who only works from 2D prints needs the prints, and the prints must then carry the full authority. The contractual frame simply names who owns the truth, so the project does not find out at the first rejected part.
Reading MBD on the Factory Floor
Model-based delivery fails at the moment the shop floor cannot read it. The welder brazing the frame, the inspector at the CMM, and the fitter aligning the guide rails all consume the product definition, and each reads it in a different medium. The pragmatic MBD rollout provides the right medium per role: the full annotated model for the machinist with a terminal, a generated dimensioned view for the inspector’s report, and a simplified pictorial drawing for the floor that marks critical dimensions and tolerances without the model’s full weight. MBD succeeds not by forcing the model on every reader but by presenting the model’s truth in the form each reader can act on.
The floor presentation also needs the annotation discipline upstream. Critical features get explicit geometric tolerances and datums; non-critical features stay uncluttered. A model that annotates everything annotates nothing, because the floor cannot tell which callout matters. MBD reads clean when the design communicates priority — the datum scheme, the critical tolerances, and the finish requirements carry the focus, and the rest of the geometry is left to the model’s natural accuracy.
Conclusion
Model-based definition is not the death of drawings; it is the end of drawings as the duplicated source of truth. For non-standard automation, where weldments and complex assemblies dominate and small teams move fast, MBD removes the translation loss between design and build. Its success depends on pragmatic boundaries: reading the annotations where the audience can read them, generating inspection data from the model, and controlling the one file that everyone trusts. Adopted that way, MBD turns the model into the memory of the project, and the machine builds itself from a single, consistent story.
