THE MASTER MODEL

Teamcenter Data-Model Mapping

Every element in the neutral bundle lands in Teamcenter as a first-class business object with its native type — not a blob attached to a dataset, not a property bag. This page is the exact map: bundle element to Teamcenter type, the nested Logical BOM that carries four domains in one tree, and the identity rules that make every re-publish an update instead of a duplicate.

Why real types matter

We could have stamped each publish into Teamcenter as an opaque file and called it integration. We deliberately did not. Every publish materializes typed items, typed relations, and real BOM occurrences — and that decision pays three ways:

Searchable. Objects we create come back through Active Workspace global search with correct type facets — during bring-up a single test round returned its objects faceted as System Block Revision, Function Revision, Logical Connection Revision, and Exchange Item Revision, with Teamcenter's own function icons. No custom index, no side database.

Viewable. Active Workspace renders our structure with its stock views: the Content tree walks the LBOM occurrences, Teamcenter auto-draws an Architecture diagram of nested System Blocks, GDE ports surface in the Interfaces views, and Seg0Allocate edges appear in the Relations graph. We wrote no viewer for any of that.

Survives us. Because the objects are native, Teamcenter's own business rules bind them — naming rules, GRM rules, structure rules. That is occasionally restrictive (see the error-46147 story below), but it is exactly why the data is trustworthy: any downstream consumer — change management, workflows, another integration — sees ordinary Teamcenter data. If our middleware disappeared tomorrow, the master model stands.

The mapping table

Every row below was created, re-published, and read back live on Capital 2512 ⇄ Teamcenter 2506 proven live. Types are configuration, not code: tc-service/config.json keys under teamcenter.* select them, so an instance that prefers the Arcadia/Capella family swaps Fnd0LogicalBlock for Sys0LogicalComp without touching a line of the pipeline.

The effective type map, as deployed:

"teamcenter": {
  "componentType":       "Fnd0LogicalBlock",
  "functionType":        "Functionality",
  "allocationRelation":  "Seg0Allocate",
  "portType":            "Fnd0LogicIntrfce",
  "functionPortType":    "Network_Port",
  "signalType":          "Signal",
  "networkType":         "Network",
  "carrierType":         "Fnd0LogicConn",
  "requirementType":     "Requirement",      // code default, overridable
  "requirementRelation": "IMAN_requirement", // code default, overridable
  "runTag":              "",
  "legacyRunTags":       ["T7"]
}

One nested LBOM, four domains

The structural backbone is a single root Fnd0LogicalBlock named <PROJECT>-LBOM. Everything beneath it is a real Fnd0LogicalBOMLine parent-child occurrence — native BOM structure that Active Workspace rolls up on its own, not a web of trace links.

With contract v1.2, the MIL-STD-1808 logical spine becomes the parent skeleton: UAV is the root's single top occurrence, the chapter nodes (24 Electrical Power, 28 Fuel) and chapter groups hang beneath it, and every domain-authored element nests under the spine node named by its parentId. Logic devices nest one level further — under the platform component they realize. The result is one tree spanning what four tools authored: the SysML spine sysml and its architect additions sysml-add, Capital's platform schematic elec and new electrical elements elec-add, and NX fuel equipment fuel-add — each element carrying its provenance and effectivity as stamped properties.

How a published component becomes an occurrence in that tree:

Proven on the UAV Platform: the full spine push landed with nested_parents = 15, occurrences_added = 25, errors = [] proven live, and the live step-7 beat — a breaker drawn in Systems Architect — created one item and one occurrence nested under LOG-ACFSCB with zero errors. Requirements deliberately stay out of this tree: they connect by relation only, keeping the root → UAV structure pristine.

Identity: item ids are the join key

One id follows an element through every tool. The Teamcenter item id is the bundle id is the Element ID property in Capital. When the hub materializes Teamcenter data into a Capital project, every function and component carries <property name="Element ID"> = its TC item id — the same slot the Cameo bridge uses for SysML GUIDs. When Capital publishes back, external-id resolution runs TC_ID property → Element ID property → Capital UID. That chain is what closed the round trip at Wildfire scale: TC-author → materialize in Capital → publish back = 0 items created, 134 existing, 199 relations existing, 0 errors.

Names are never identity — a rename changes a mutable display property, never the id. And because regenerating a logical design mints all-new Capital-internal UIDs, the logic publisher derives stable ids from what survives regeneration:

runTag namespacing. During bring-up, every test round prefixed all created ids and names with a tag (T1…T7) — disposable namespaces inside a shared instance. Production runs with runTag = "", and that is mandatory: cross-publish parent resolution looks spine ids up untagged, so a lingering tag silently breaks nesting. Estates minted under an older tag are not stranded — teamcenter.legacyRunTags lets the push adopt those ids instead of re-minting (production mode only). The Wildfire T7 estate was adopted exactly this way: the publish-back reported zero creates.

What Active Workspace shows

Because the mapping targets native types, Active Workspace is a working client of this data with no customization. Opening <PROJECT>-LBOM in Content renders the nested logical structure exactly as published: one child UAV, the 1808 chapters beneath, and fuel, electrical, and logic-detail elements nested under their logical parents.

The port GDEs we attach are the exact objects AW's Interfaces views read — Fnd0LogicIntrfce and Network_Port GDELine occurrences surface as interfaces on the block occurrences. The Relations graph shows Seg0Allocate edges from any revision node. And requirements navigate both ways: open REQ-000123 and its IMAN_requirement relations fan out to the seven inverted-flight function revisions (satisfies) and the two architecture adds (derives); open any function revision and the relation points back.