Why CAD Files Need Governance
A 3D CAD model created by one engineer and opened by another six months later should be immediately navigable: the feature tree should be readable, the model should be stable, and the intent of each modeling decision should be apparent. In most engineering teams, this is not the reality. The model opens with suppressed features, broken references, dimensions on sketch planes that cannot be understood without interrogating the original engineer, and a feature tree named Feature1, Feature2, Boss-Extrude3.
The cost of poor CAD governance is paid every time a model is reused, revised, or handed off. It accumulates invisibly in time spent reconstructing intent, rebuilding broken features, and avoiding modifications because the model behavior is unpredictable. A team-wide modeling standard, consistently applied, eliminates most of this cost.
File Naming Conventions
File names are the primary identifier for a CAD model across its entire lifecycle — in the file system, in the PDM system, on drawings, and in BOMs. A good naming convention encodes enough information to identify the file without ambiguity while remaining short enough to be practical.
Elements of a robust naming convention:
- Part number as the primary identifier: the part number is unique and permanent; descriptive names change as designs evolve
- Revision or version indicator: embedded in the file name or managed by the PDM system — never both, or confusion results
- Consistent separators: choose one (underscore, hyphen, or period) and use it everywhere; mixed separators cause sorting and search failures
- No spaces: spaces in file names create path errors in scripts, PDM integrations, and some CAD cross-references
- No special characters: parentheses, slashes, ampersands, and quotes cause failures in multiple contexts
Example of a workable convention: [ProjectCode]-[PartNumber]-[Rev].sldprt → AB-100234-A.sldprt. The part number is the core identifier; the project code scopes the number space; the revision suffix is managed explicitly.
Assembly files, drawing files, and simulation files associated with the same part should share the part number as the root name, with a consistent suffix to identify the file type: AB-100234-A.sldprt (part), AB-100234-A.slddrw (drawing), AB-100234-ASM-A.sldasm (assembly).
Feature Tree Structure and Naming
The feature tree of a 3D model is a design history document. Anyone who opens the model should be able to read the feature tree and understand how the part was built and why. This requires intentional naming and structuring.
Feature Naming Principles
- Name features by their function, not their type: “BearingBoreFront” not “Cut-Extrude3”; “MountingFlange” not “Boss-Extrude5”
- Name sketches immediately after creation: “ProfileSketch” or “CutoutProfile”, not “Sketch4”
- Group related features under folder objects (or equivalent) in systems that support them: “BoreGroup”, “BracketFeatures”, “ThreadDetails”
- Place reference geometry (planes, axes, coordinate systems) together near the top of the tree, named by their geometric meaning: “TopDatumPlane”, “RotationAxis”
Feature Structure Rules
- Build the base feature (the largest, most fundamental shape) first
- Add material before removing it where possible — solid-to-solid operations are more robust than cut-heavy trees
- Avoid parent-child relationships that cross feature groups — when a sketch in group B references geometry from group A, a change to group A unpredictably breaks group B
- Fully define all sketches — under-defined sketches are a source of unexpected model changes when dimensions are modified
- Do not use in-context references from assembly modeling for production parts — they create fragile external dependencies
Assembly Structure
Assembly CAD files have additional organization requirements beyond individual part models:
- Top-level assembly: contains only major sub-assemblies and individually purchased standard components — never individual manufactured parts directly, unless the assembly is very simple
- Sub-assembly boundaries: correspond to physical assembly groups — what is assembled together in one station belongs in one sub-assembly
- Mate naming: name mates that define critical relationships, especially in flexible assemblies or assemblies with designed-in adjustment
- Standard component libraries: fasteners, bearings, seals, and other purchased components should come from a shared library, not be modeled from scratch in each assembly
File Organization and PDM
| Organization Level | Tool | Key Rule |
|---|---|---|
| Individual file naming | Naming convention document | Part number as primary key; no spaces or special characters |
| Folder structure | Shared file server or PDM | Organized by project then component type; never by engineer name |
| Version control | PDM or vault system | Only one checked-in version per revision; working copies in personal workspace |
| Cross-references | PDM dependency tracking | Verify all references are resolved before checking in |
| Archive and release | PDM release workflow | Released files are read-only; changes require new revision |
Enforcing Standards Across a Team
A modeling standard that exists only as a document is not a standard — it is a suggestion. Effective enforcement combines three elements: training (so engineers understand the rules and their reasons), templates (so compliance is the path of least resistance), and review (so deviations are caught before they propagate).
CAD review should include a quick model quality check alongside the drawing check: is the feature tree legible? Are sketches fully defined? Are there broken references? Five minutes of model review prevents hours of reconstruction later.
FAQ
Q: We have hundreds of legacy CAD files that don’t follow any standard. How do we manage the transition?
Do not attempt to retrofit standards onto all legacy files simultaneously — the effort is enormous and the disruption to ongoing work is unacceptable. Instead: apply the new standard to all new files from a fixed date; convert legacy files to the new standard when they are opened for revision (not proactively); and maintain a register of legacy files with their non-standard status so new engineers are not confused. Incremental migration over one to two years is more practical than a big-bang conversion.
Q: Should individual engineers be allowed to use personal modeling shortcuts that deviate from the standard?
Personal shortcuts that do not affect the deliverable (the checked-in, released model) are the engineer’s business. Personal shortcuts that result in non-standard checked-in models are the team’s problem. The standard applies to released files; pre-release working copies are the engineer’s workspace. Clarity on this boundary reduces resistance to standards adoption.
Q: Our CAD software updates frequently and sometimes breaks old models. How do we manage this?
Maintain a testing protocol for major CAD version updates: before deploying the update, open a sample of representative legacy files and verify that critical models rebuild correctly. For models that break, evaluate whether the fix is simple (reference repair) or requires rebuilding — budget the effort before the update goes live. Delay the update if critical production models cannot be stabilized in the available time.
コメント