## Overview Large assembly projects (thousands of parts, multiple engineers) fail most often due to **lack of upfront planning** — not lack of engineering skill. File management, naming conventions, revision control, and assembly strategy must be decided **before the first part is created**. The cost of planning is typically a small fraction (~10%) of the cost of recovering from unplanned chaos. --- ## Key Concepts - **Skeleton Model Technique** – a single reference part containing key geometry that all components reference (hub-and-spoke) - **Master Model Technique** – a complex surface/solid body from which multiple child components are derived - **Product Data Management (PDM)** – software systems that control file versioning, check-in/check-out, and reference tracking - **In-Context References** – geometry in one part driven by geometry of another part within an assembly context - **Single-Point Database** – each piece of information stored in one file only; other files reference it via external links --- ## Detailed Notes ### Common Failure Modes in Unplanned Assemblies - Broken external references from moved files (absolute paths invalidated) - Lost work from uncontrolled overwrites (no check-in/check-out) - Duplicate parts with conflicting dimensions (no naming convention) - Inability to generate accurate Bills of Materials (no custom properties) - Cascading project delays and contractual penalties --- ### Assembly Modelling Techniques #### Skeleton Model Technique - A **single part file** containing only key geometry: interfaces, mounting locations, spatial envelopes, critical dimensions - All components reference the skeleton — **not each other** - Creates a **hub-and-spoke** reference structure - Best for: industrial machinery, plant layout, equipment with many mechanical interfaces - **Advantages:** centralized change propagation, independent sub-assembly work, low circular reference risk #### Master Model Technique - A **single master part** with complex surfaces/solid bodies from which multiple child components derive - Results in many **multi-body parts** - Best for: consumer products, duct systems, automotive body panels, organic/complex shapes - **Advantages:** surfaces created once and shared, automatic updates to derived components --- ### Technique Selection Framework | Factor | Skeleton Model | Master Model | |---|---|---| | **Primary geometry** | Interfaces, envelopes, datums | Complex surfaces, organic forms | | **Typical use** | Industrial machinery, plant design | Consumer products, automotive | | **Team collaboration** | Excellent — clear interfaces | Good — requires surface management | | **Reference structure** | Hub-and-spoke | Parent-child | | **Change propagation** | Predictable, centralized | Predictable but can cascade | | **Circular reference risk** | Low | Moderate | | **Multi-body usage** | Minimal | Extensive | | **Learning curve** | Moderate | Moderate to High | --- ### Part Numbering Approaches #### Intelligent Numbering - Part number **encodes information**: project code, assembly zone, part type, sequence - Example format: `[Project]-[Zone]-[Type]-[Seq]` - **Pros:** identifiable without opening files, natural grouping, aids communication - **Cons:** requires upfront scheme design, conflicts when parts move between zones, can become overly complex #### Non-Intelligent (Sequential) Numbering - Each part gets the **next available number** — carries no descriptive meaning - All context stored in **custom properties and metadata** - **Pros:** simple, no renumbering needed, no classification debates - **Cons:** meaningless without a database/PDM, harder to identify at a glance --- ### Revision Scheme Best Practices - Use **alphabetical** for major revisions, **numerical** for minor - Track revisions via **custom properties or PDM metadata** — **never in the file name** - Embedding revision in file names creates separate files, breaking all existing assembly references - Define **clear triggers** for what constitutes a new revision before the project starts - Establish an approval process (self, peer, or formal workflow) based on project requirements --- ### In-Context Reference Management | Rule | Rationale | |---|---| | Keep references **as simple as possible** | Complex chains cause unpredictable rebuilds | | Reference **one skeleton or master model** | Hub-and-spoke is manageable; webs are not | | **Never** create circular references | A → B → A creates infinite rebuild loops | | **Document** every in-context reference | You can't manage what you don't track | | **Lock** references when design is stable | Prevents unintended change propagation | | **Minimize** cross-sub-assembly references | Keep references within the same level | **Reference Hierarchy (safest → most dangerous):** 1. Part → Skeleton ✅ Ideal 2. Part → Master Model ✅ Good 3. Part → Part (same sub-assembly) ⚠️ Acceptable if documented 4. Part → Part (cross sub-assembly) ⚠️ Extreme caution 5. Circular (A → B → A) ❌ Never acceptable --- ### Four Pillars of Strategy Implementation #### Pillar 1: Document the Approach - Write down **all** procedures: naming, revision scheme, assembly technique, reference rules, templates, storage, workflows - **Undocumented procedures mutate, get forgotten, and disappear** - Documentation time is a fraction of the time to fix problems caused by missing procedures #### Pillar 2: Make It Accessible - Store procedures on a **shared location** (intranet, common drive) - Maintain a **single source of truth** — one location, one version - Include **quick-reference cards** for daily workflows - Make documentation **searchable** #### Pillar 3: Communicate Continuously - Discuss procedures at every planning meeting - Address deviations **immediately and constructively** - Celebrate system wins to reinforce compliance #### Pillar 4: Standardize Templates and Settings - **Part template:** custom properties, material defaults, unit system pre-configured - **Assembly template:** BOM structure settings, display states - **Drawing template:** title block linked to custom properties, standard views, dimension styles - Embedding required fields in templates ensures engineers **cannot forget** mandatory metadata --- ### Essential Custom Properties for Every Part | Property | Type | Purpose | |---|---|---| | Part Number | Text | Unique identifier | | Description | Text | Human-readable description | | Material | Text | Material specification | | Author | Text | Original creator | | Project | Text | Project identifier | | Revision | Text | Current revision level | | Weight | Number | Calculated or specified mass | | Finish | Text | Surface treatment/coating | | Vendor | Text | Supplier (purchased parts) | | Cost | Number | Unit cost for estimating | | Status | Text | Draft / In Review / Released | | Date Created | Date | Original creation date | | Date Modified | Date | Last modification date | **Why custom properties matter:** - Feed directly into **Bills of Materials** (no manual BOM creation) - Serve as **search criteria** in PDM systems - Enable **advanced selection** filtering in assemblies - Can trigger **workflow transitions** automatically --- ### System-Level Performance Settings | Setting | Recommendation | Impact | |---|---|---| | **Lightweight mode** | Enable for 1000+ part assemblies | Reduces memory and load time | | **Large Assembly Mode threshold** | Set to typical assembly size | Auto-optimizes display/rebuild | | **Rebuild behaviour** | Manual rebuild for very large assemblies | Prevents auto-rebuild on every edit | | **Image quality** | Low for WIP; high for final review only | Lower quality = faster performance | | **Verification on rebuild** | Disable during design; enable at milestones | Reduces rebuild time | | **File cache size** | Maximize based on available disk space | Faster access to frequent components | | **Background processes** | Reduce auto-recover frequency, disable auto-scroll | Reduces system overhead | --- ### File Management Fundamentals #### Single-Point Database Concept - Information stored in **one file only**; other files **reference** it - References use **absolute paths** — if a file moves, the reference breaks - No **reverse file pointers** by default (a component does not know which assemblies use it) - PDM systems solve this via a **relational database** tracking both directions (**"where used"** capability) #### Manual Data Management Methods (and Why They Fail) | Method | How It Works | Key Failures | |---|---|---| | **Central Network Storage** | All files on a shared network; edit in place | No history, no revision control, slow performance, no overwrite prevention | | **Copy-Local-and-Return** | Copy to local drive, edit, copy back | Last-save-wins; no enforcement mechanism; divergent local copies | --- ### Product Data Management (PDM) #### Core Functions 1. **Search and find** referenced files by properties/relationships 2. **BOM generation** and **"where used"** tracking (forward and reverse references) 3. **Collaboration and change control** via check-in/check-out and workflows 4. **Revision history** and **secure vault storage** with full rollback capability #### Workgroup vs. Enterprise PDM | Capability | Workgroup PDM | Enterprise PDM | |---|---|---| | Multi-user access | ✅ Controlled | ✅ Controlled | | Overwrite prevention | ✅ Check-in/check-out | ✅ Check-in/check-out | | Version control | ✅ Automatic | ✅ Automatic (versions + revisions) | | Revision schemes | Single | Multiple | | Workflows | Single | Multiple | | Search | Property-based | Fast SQL-based | | Multi-site support | ❌ Single vault | ✅ Vault replication | | Change notifications | ❌ | ✅ Automatic | | Database backend | Standard | SQL | | Cost | Moderate | Higher | #### PDM Daily Workflow 1. **Search** vault for file (by part number, description, or any property) 2. **Check out** file → copied to local cache; locked in vault 3. **Edit locally** → fast performance, no network latency 4. **Check in** → new version saved; previous version preserved; change logged; file unlocked 5. **Notifications sent** → engineers with referencing assemblies are alerted --- ### Complete Pre-Project Planning Checklist #### Phase 1: Pre-Design Planning 1. Estimate assembly size and composition 2. Choose assembly technique (skeleton or master model) 3. Define naming convention (intelligent or sequential) 4. Establish revision scheme and triggers 5. Define in-context reference rules and maximum depth 6. Select data management method (PDM level) 7. Define document workflow (states, transitions, approvers) 8. Create custom property list for parts, assemblies, drawings #### Phase 2: Infrastructure Setup 9. Create standardized part template with all custom properties 10. Create standardized assembly template with BOM settings 11. Create standardized drawing template with auto-populating title block 12. Configure PDM vault structure (folders, permissions, workflows) 13. Define system-level performance settings for all workstations 14. Build skeleton model or master model 15. Validate templates and model with a test sub-assembly #### Phase 3: Documentation and Communication 16. Write procedures document covering all Phase 1 decisions 17. Create quick-reference cards for daily workflows 18. Publish documentation to shared location 19. Conduct team kickoff meeting to review procedures 20. Schedule regular check-ins for questions and deviations #### Phase 4: Ongoing Enforcement 21. Monitor compliance with naming conventions and property completion 22. Review in-context references periodically for unplanned cross-references 23. Audit vault for orphaned files, duplicates, or broken references 24. Update procedures as lessons are learned 25. Onboard new team members using documentation (not tribal knowledge) --- ## Diagrams ### Assembly Technique Selection ```mermaid flowchart TD A[New Large Assembly Project] --> B{Primary Geometry Type?} B -->|Interfaces, Envelopes, Datums| C[Skeleton Model Technique] B -->|Complex Surfaces, Organic Forms| D[Master Model Technique] C --> E[Hub-and-Spoke References] D --> F[Parent-Child Derived Parts] E --> G[Independent Sub-Assembly Work] F --> H[Shared Surface Updates] ``` ### In-Context Reference Hierarchy ```mermaid flowchart TD A[In-Context Reference Choices] --> B["Part → Skeleton ✅ Ideal"] A --> C["Part → Master Model ✅ Good"] A --> D["Part → Part Same Sub ⚠️ Caution"] A --> E["Part → Part Cross Sub ⚠️ High Risk"] A --> F["Circular A → B → A ❌ Never"] ``` ### PDM Check-Out / Check-In Workflow ```mermaid flowchart TD A[Search Vault] --> B[Check Out File] B --> C[File Copied to Local Cache] B --> D[File Locked in Vault] C --> E[Edit Locally] E --> F[Check In File] F --> G[New Version Saved to Vault] F --> H[Previous Version Preserved] F --> I[Change Log Updated] F --> J[File Unlocked] J --> K[Notifications Sent to Referencing Engineers] ``` ### Project Planning Phases ```mermaid flowchart LR A[Phase 1: Pre-Design Planning] --> B[Phase 2: Infrastructure Setup] B --> C[Phase 3: Documentation & Communication] C --> D[Phase 4: Ongoing Enforcement] ``` --- ## Key Terms - **Skeleton Model** – a single reference part containing key assembly geometry; all components reference it instead of each other - **Master Model** – a part with complex surfaces/bodies from which multiple child components derive their geometry - **PDM (Product Data Management)** – software that manages file versioning, access control, and reference tracking for engineering data - **In-Context Reference** – a geometric relationship created between parts within the context of an assembly - **Single-Point Database** – architecture where each piece of data exists in one file only; others reference it - **Absolute Path** – a complete file location path; breaks if the file is moved - **Check-In / Check-Out** – a PDM mechanism that locks files during editing to prevent concurrent overwrites - **Where Used** – a PDM query showing all assemblies that reference a given component - **Custom Properties** – metadata fields embedded in part files (e.g., material, revision, cost) that drive BOMs and searches - **BOM (Bill of Materials)** – a structured list of all components in an assembly, generated from custom properties - **Vault Replication** – synchronising a PDM vault across multiple physical locations for distributed teams - **Intelligent Numbering** – a part numbering scheme where the number itself encodes information (project, zone, type) - **Non-Intelligent Numbering** – sequential numbering where the part number is a unique ID only; all context lives in metadata --- ## Quick Revision - **Plan before modelling** — the cost of planning is ~10% of the cost of recovering from unplanned chaos - Choose your **assembly technique** (skeleton vs. master model) before creating the first part - **Never embed revisions in file names** — use custom properties or PDM metadata to track revisions - Keep in-context references in a **hub-and-spoke** pattern; never allow circular references - **Custom properties** are the foundation for automated BOMs, PDM search, and workflow triggers - **PDM systems** prevent overwrites, track versions, and provide "where used" capabilities that manual methods cannot - **Enterprise PDM** adds vault replication, multiple workflows, SQL search, and change notifications over workgroup-level PDM - **Standardised templates** eliminate repetitive setup work and ensure every file starts with required metadata - **Document all procedures**, store them in a single accessible location, and enforce them continuously - **Onboard new team members** from documentation — not tribal knowledge