2. Simulation data management (SDM) fundamentals

Simulation Data Management (SDM) is the discipline of capturing, organizing, governing, and delivering the data produced by and consumed by numerical simulation — geometry, meshes, material definitions, solver decks, boundary conditions, results, and the metadata that binds them together. Where a CAD data management system answers "what is the design?", SDM answers a harder question: "what was simulated, on which version of the design, with which assumptions, and what did we conclude?" That distinction matters because simulation data is orders of magnitude larger than CAD data, is frequently derived rather than authored, and is only meaningful when the full input-to-result lineage is preserved.

A useful working definition for engineering teams is: SDM is the set of processes, metadata schemas, and repository services that make simulation inputs, outputs, and decisions traceable, reusable, and auditable across the product lifecycle. Three properties are implicit in that definition. Traceability means every result can be walked back to its exact inputs. Reusability means a validated model can be found and re-applied without rebuilding it. Auditability means a reviewer or regulator can reconstruct why a design decision was made.

What falls inside the SDM scope

SDM scope is best understood as a data lifecycle rather than a folder structure. The table below summarizes the principal object classes and the governance question each one raises.

Note what is not in scope: SDM does not replace the solver, the meshing tool, or the CAD authoring system. It sits above them as a system of record and orchestration layer. A common failure mode is treating a shared network drive with a disciplined naming convention as "SDM" — it captures files but not relationships, so lineage breaks the moment a geometry revision changes.

Where SDM sits relative to PLM and SPDM

Three acronyms are frequently conflated, and clarifying them early prevents years of architectural confusion.

PLM (Product Lifecycle Management) is the enterprise system of record for the product definition: requirements, CAD structure, BOM, change management, and release workflow. It is optimized for relatively small, structured, revision-controlled objects and for cross-functional process governance.

SPDM (Simulation Process and Data Management) is the narrower, simulation-specific implementation layer. It provides the simulation-aware repository, the CAE metadata model, solver integration, job submission, and result visualization. In practice, "SPDM" is often the product category name (e.g., a commercial simulation data backbone), while "SDM" is the discipline. Many organizations use the terms interchangeably; for this course, treat SPDM as the tooling that implements SDM.

SDM is therefore the overarching practice, and the integration architecture typically looks like a federated model: PLM owns the released design and the requirement; SPDM owns the simulation objects and their lineage; a linkage layer connects the two so that a simulation references a specific PLM part revision rather than a loose file.

Integration mechanics in practice

The integration between PLM and SPDM is where most implementations succeed or fail. A robust pattern is the reference-not-copy rule: the SPDM object stores a pointer to the PLM part revision identifier, not a duplicated CAD file. When the design changes from Rev C to Rev D, the simulation object remains bound to Rev C until an engineer explicitly creates a new simulation revision against Rev D. This preserves the historical record while making the delta visible.

Consider a concrete example. A bracket assembly is released in PLM as part BRK-2041, revision C. An engineer creates a static structural study in SPDM. The study metadata should capture at minimum:

study_id:        SIM-BRK-2041-0007
plm_part:        BRK-2041
plm_revision:    C
requirement:     REQ-STR-0118  (max von Mises < 210 MPa at 3g load)
solver:          Abaqus 2023, double precision
mesh:            C3D10, 412,880 elements, global size 2.0 mm
materials:       Al 6061-T6 (E = 68.9 GPa, nu = 0.33, Sy = 276 MPa)
load_case:       3g inertial, fixed at 4 bolt holes
result_kpi:      max von Mises = 187 MPa  →  margin = 11.0%
verdict:         PASS
reviewer:        J. Okafor, 2024-06-11

With this record, a reviewer six months later can answer every audit question without opening a single solver file. The margin calculation is explicit: (210 − 187) / 210 ≈ 11.0%. If the requirement later tightens to 180 MPa, the same record immediately shows the design would fail, and the change request can be linked to the affected study.

Common integration pitfalls

• Duplicated geometry. Copying CAD into the SPDM vault creates two sources of truth. Prefer references with revision pinning.
• Metadata in filenames. Encoding revision, load case, and date into a filename works until someone renames a file. Store these as structured attributes.
• Result files without extraction. Storing a 40 GB result database without extracting KPIs makes the data technically present but practically unusable. Always persist the decision-relevant scalars alongside the raw output.
• One-way synchronization. If PLM revision changes never propagate to SPDM, engineers silently simulate obsolete geometry. Implement a change notification or a periodic reconciliation query.

The scope of SDM therefore extends beyond storage into query, linkage, and decision support. Once the federated architecture is in place — PLM owning the released definition, SPDM owning the simulation lineage, and a linkage layer binding them — the remaining chapters of this course build on that foundation: metadata schemas, quality gates, verification and validation records, and the metrics that tell you whether the simulation data estate is actually trustworthy.