WHERE THIS GOES

The Systemscenter Roadmap

The systems center works: one neutral logical structure, mastered in Teamcenter, that every domain tool reads and writes. This page is where we take it next — from a proven integration to an Active Workspace product, and from three Capital tools plus NX to the whole Xcelerator portfolio.

From integration to product

The proof-of-concept phase ended with a specific, measurable claim: the systems-center model survives contact with real scale. On the Wildfire Platform we authored the entire architecture in Teamcenter, materialized it into Capital Systems Architect as a native project, and published it back — and the hub resolved every single object to its original Teamcenter identity. proven live

Zero creates on republish matters more than any single feature. It means identity, adoption, and idempotent writes — the hard problems of a bidirectional integration — are solved in the hub, not papered over per tool. And the solution turned out not to be Capital-specific at all. The pieces that made Wildfire work are the pieces that make any tool work:

• Stable external identity with a defined precedence (TC_ID → Element ID → tool-native id), so a design that leaves Teamcenter and comes back still knows who it is.
• Ensure-then-adopt writes — the hub matches existing Teamcenter objects (including tool-minted ids like Capital's CONN-<n> connections, adopted by endpoints and carrier) before it ever creates.
• Merge-preserve enrichment — republishing from a tool that doesn't carry parentage, provenance, or effectivity never wipes them; the hub derives provenance from the publisher, defaults effectivity, and fills parents from patch maps.
• Parent-resolved nesting — every component lands under the right node of the shared MIL-STD-1808 spine, whichever tool published it.

The generality claim was then tested the honest way: we brought up a second authoring stack. The NX Diagramming reader — a single NXOpen journal emitting the same bundle — pushed a fluid schematic into Teamcenter through the unchanged hub the same day it was written. proven live The one-pager's conclusion stands: the neutral data contract is the hard, proven part; productizing is mostly the presentation layer.

The Active Workspace path

Decision, made 2026-07-04: Systemscenter ships as an Active Workspace application first, not a standalone web app. The common logical schematic structure becomes a first-class PLM view — same shell, same navigation, same auth and session as the rest of Teamcenter — rather than a side tool with its own login and look.

The reasons are practical, not aesthetic. AW runs on the same Teamcenter SOA the neutral bundle is assembled from, so the data is already where the app lives. AW brings the Siemens design language, dark/light theming, and accessibility for free. And users reach it where they already work — a systems engineer browsing the LBOM in AW should fall into the cross-domain map without changing tools.

This is further along than a slideware decision. Two linked lenses over the neutral structure exist and are verified against real Teamcenter data:

• Structure Map — the cross-domain relationship graph: columns Functional | Platform | Logic | Fluid (NX), nodes colored by domain and labeled with their TC type, edges for allocation / realizes / conductor / connection / signal, hover-to-isolate, domain and edge-type filters. proven live
• Structure Tree — the LBOM exactly as Teamcenter nests it (191 rows on Wildfire), with provenance dots sysml sysml-add elec-add fuel-add, MIL-STD-1808 chapter badges, effectivity pills, and a domain-participation filter. proven live

The on-ramp to AW is already built: a real SWF solution (SWF is Active Workspace's own declarative React framework) lives in systemscenter/app/, with the map ported into an <ssc-structure> custom element reading the neutral bundle from the hub. It builds offline from vendored @swf/* tarballs and renders both lenses with live data across all four demo projects. proven live What remains is the AW-integration engineering partial:

• Extension shape for TC 2506/2512 — declarative view-model plus custom component, or a full custom location that cleanly hosts a d3/SVG canvas.
• Data path — call SOA directly from the AW client, or keep tc-service as a backend-for-frontend serving the already-proven bundle assembly.
• Packaging and placement — how the module is built, staged, and deployed; a global "Systemscenter" location versus a contextual tab on an object.

First move, per the one-pager: stand up a hello-world custom location in the dev AW, then port the Structure Tree first — simplest lens, highest signal.

Near-term engineering roadmap

These are the concrete items between today's proven baseline and a pilot-hardened product. Sizes are engineering judgment; status distinguishes what is proven, what is partially landed, and what is planned.

The bigger picture: one contract for the portfolio

The neutral bundle was designed tool-agnostic, and the cost of joining it is now empirically known: one reader that emits components, connections, and functions as JSON, plus a POST to the hub. The hub does everything else — provenance from the publisher's identity, effectivity defaults, parent patch maps, domain-participation derivation, idempotent Teamcenter push. That is the whole integration burden NX paid, and it joined the digital thread in a day.

Two portfolio spokes are next, and both are cheaper than NX was because their data is already in the schema:

• Polarion — requirements. The contract carries requirementLinks[] today, and the Teamcenter mapping (Requirement items, IMAN_requirement relations, the REQ-nnnnnn naming rule) is proven live. Polarion becomes the requirements master publishing the same links; the trace thread from requirement to function to logical element to domain design is already rendered in the tree.
• Simcenter Amesim — parameters. Maturing engineering parameters are first-class in the contract, keyed by maturity state:

{ "name": "weight", "unit": "kg",
  "values": { "budget": "3.5", "simulated": "3.2" } }

// suggested states, in precedence order:
// target → budget → simulated → product → tested

A simulation run publishing simulated values against the same component identities is a reader plus a POST — the schema, the identity model, and the visualization are waiting for it. (In the 13-step demo scenario this is step 12, narrated today rather than run.)

The design decision that makes portfolio convergence safe is already in: one element, one identity, domains as a participation set. A fuel pump is not three objects in three tools — it is one object that participates in FUEL, ELECTRICAL, and SOFTWARE, with participation derived by the hub from declared attributes and connection evidence. Every new spoke enriches the same object instead of forking it. proven live

What a pilot program needs

For engineering leadership weighing a pilot: the scenario we would run is the 13-step inverted-flight thread — requirement to functions to logical architecture to fuel, electrical, and software domains — and eleven of its thirteen steps execute live today (the two narrated steps are PCB/software BOM integration and the Amesim leg). Here is what a pilot actually requires.