The demonstration → Siemens Xcelerator

One article, carried across the whole portfolio

A single fictional engineering problem taken from mission need to computed readiness, using the Siemens Xcelerator portfolio as it actually installs, with every tool that ran separated from every tool that did not.

Unclassified throughout MSP-2, fictional article No F-35 data used or implied

1What was built

The article is the MSP-2 mission systems processor DMSMS refresh: a fictional radar signal-processing card whose primary FPGA has gone end of life. Two candidate architectures answer it. Candidate A is a pin-compatible part swap with a minor board re-spin. Candidate B consolidates the FPGA and its companion processor onto a single system on chip.

It was chosen because it is the customer's own stated problem, because it forces all five of the JPO's IV&V techniques to be genuinely necessary rather than decorative, and because two candidates on a shared parent is what makes a trade study real instead of a formality.

The finding the demonstration exists to produce. Candidate A fails on thermal. The pin-compatible part dissipates 7.4 W more in the same footprint and reaches 110.12 °C against a 105 °C limit, a margin of -5.12. Only the multi-mode technique could have found it. A programme running simulation and emulation alone ships that card and discovers the problem in a hot-day flight test.

That figure is measured, not constructed. Simcenter Flotherm ran the baseline and candidate A on a bit-identical 213,616-cell mesh with identical boundary conditions, so the 11.76 °C rise is attributable to the extra 7.4 W alone, at 1.59 °C/W. Candidate B measures 100.16 °C and passes.

Thermal is not the only way a “pin-compatible” part hides risk. A documented failure mode elsewhere in the industry: a monolithic-die FPGA replaced by a footprint-compatible part built as a multi-die system-in-package, with far less bandwidth between die than the original die's own internal fabric. A logic block too large for one die gets automatically partitioned across die by the vendor's own implementation tools, introducing inter-die serialization/deserialization latency that does not exist in the pre-partition design, and that standard emulation does not model, because it is a place-and-route and packaging artifact, not a property of the logic itself. Programmes that missed this at design time have shipped hardware that failed unpredictably in the field, needed a re-architecture, and lost well over a year of schedule with permanently degraded end performance to show for it. It is exactly the risk a hardware-accurate twin is built to catch.

Updated 2026-08-18: this moved from narrative to a validated model. A two-chiplet variant of the Stage 3 twin binds Candidate A's input and output transceivers to opposite die, so the filtered sample stream is structurally forced across a modelled die-to-die link rather than a size-threshold guess about what a vendor's tools might do. It is authored and passes Architect Explorer's own schema and logical validation. Turning that into a measured pass/fail threshold is blocked on a hardware-generation fault in this tool install (reproduced against Siemens' own unmodified shipped tutorial, not this model), not on the modelling itself, evidence is on file for the install owner. That is the next thing this stack proves, and it is one blocked build step away, not a redesign.

2What Siemens Xcelerator is

Xcelerator is not one application. It is three things at once, and the distinction matters for a programme office evaluating a partner:

A portfolio. The design, simulation, electronics, manufacturing and lifecycle software, spanning mechanical, electrical, electronic, software and process domains under one commercial roof.
A platform. A common data and identity layer, cloud or on-premises deployment, and an open interchange posture so that a customer is not required to standardise on a single authoring tool to keep one record.
An ecosystem. A partner and marketplace model, which matters here because the F-35 enterprise will never be a single-vendor estate and any honest architecture has to assume mixed tooling across the primes.

For this demonstration the relevant claim is narrow and checkable: the portfolio covers every stage of the JPO's own Stage 0 to Stage 6 future-state chart, through to sustainment, on Teamcenter Service Lifecycle Management and its Xcelerator portfolio siblings.

3The stack, by domain

Teamcenter: the system of record

The hub. Everything else writes into it. In this demonstration the tier carries the mission layer, the requirement set, both candidate architectures and the readiness metrics as native typed objects, not as attached documents.

Teamcenter Systems Engineering for requirements, functions and logical architecture, with an operational analysis layer for mission, mission phase, capability and environmental conditions.
Active Workspace as the browser client, with style sheets and report definitions carrying the readiness surfaces.
Program Planning and Schedule Manager for the programme structure, gates and integrated master plan.
Simulation Process and Data Management so a simulation result is a managed object with provenance rather than a file on a share.
Manufacturing and Quality for the EBOM to MBOM transformation, process planning and inspection definitions.
Classification, Dispatcher and Workflow for taxonomy, out-of-band translation jobs and governed state changes.
Polarion for application lifecycle management on the software side, and Teamcenter Service Lifecycle Management for the sustainment end.

Siemens EDA: the electronics

Questa for functional simulation, UVM coverage, formal property analysis, clock domain crossing and autocheck, plus SystemC and TLM co-simulation.
Innexis as the virtual and hybrid twin layer: Architect Explorer for the hardware and software fidelity model that runs real firmware against a modelled processor, and Virtual System Interconnect for system-of-systems virtual integration.
Veloce for hardware-assisted emulation and prototyping, which is the box the incumbent already owns on this programme.
HyperLynx for signal integrity, power integrity and EMI, and Xpedition for the PCB itself.
Calibre for physical verification and signoff, Tessent for design for test, and Solido for variation-aware characterisation.

Simcenter: the physics

Simcenter Flotherm and Flotherm XT for electronics thermal, which is the tool that produced the finding above.
Simcenter 3D for structural, vibration, thermal and acoustic analysis, and Simcenter Amesim for 1D multiphysics system simulation.
Simcenter STAR-CCM+ for computational fluid dynamics where the problem is genuinely three dimensional.
Simcenter Testlab with SCADAS hardware on the physical test side, closing the loop from prediction back to measurement.
Simcenter romAI for reduced-order models that run in real time, which is what a hardware-in-the-loop rig needs.
Simcenter MADe for reliability, availability, maintainability and safety, including FMEA and criticality.

NX and Capital: the physical and electrical design

NX for mechanical design, CAM, and schematic and diagramming work such as multi-domain platform schematics.
Mechatronics Concept Designer where mechanical, electrical and control behaviour need to be evaluated together.
Capital for the electrical and electronic systems architecture: systems architect, logic, harness design and the modular interface architecture the JPO's own integration slide asks for by name.

The rest of the estate

Opcenter for manufacturing operations, Insights Hub for operational data from fielded assets, Mendix for the low-code applications that surround a programme without becoming shadow systems, and Solid Edge where a supplier does not run NX.

4The demonstration stage by stage

Stages are numbered to match the JPO's own Stage 0 to Stage 6 future-state chart, because they will recognise their own roadmap.

Stage	What happens	Products	15288 clause
0	Mission, mission phases, capability and environmental conditions. The system model is authored in a competitor's tool and managed through the thread anyway.	Teamcenter operational analysis layer, MBSE Integration Services, Cameo	6.4.1, 6.4.2
1	Twenty-two requirements imported rather than retyped, each carrying its planned verification techniques. The plan is generated from the assignment, not authored as a document.	Teamcenter Systems Engineering, ReqIF interchange	6.4.3, 6.4.9
2	Two candidate architectures under one parent, with eight trade criteria frozen and timestamped before any evidence exists.	Teamcenter Decision Management, HEEDS for the sweep	6.3.3, 6.4.6
2b	Multi-mode analysis. Junction temperature, eye height and EMI margin, vibration. This is where candidate A fails and where a pure-EDA vendor has no answer.	Simcenter Flotherm, HyperLynx, Simcenter 3D, managed through Simulation Process and Data Management	6.4.6
3	Hardware-accurate twin. Coverage, formal property analysis, clock domain crossing, and the operational flight program running against the hardware model.	Questa, Innexis Architect Explorer	6.4.7, 6.4.8, 6.4.9
4	A modular interface to a neighbouring subsystem twin, defined so it can be counted rather than asserted: 20 signals over 32 pins, and a measured difference in where the safety nets terminate.	Capital, authored and validated here; Innexis Virtual System Interconnect proposed for the system-of-systems case	6.4.8
5, 6	Hardware in the loop and flight test, with results returning against the same requirement ids.	Simcenter romAI, Testlab, SCADAS	6.4.11 (partial), 6.4.12

5What actually holds it together

The portfolio is the easy half of the answer. The hard half is that a programme office cannot be asked to standardise every partner on one vendor, so the thread has to survive mixed tooling. Four things carry it here:

One identifier, everywhere. Evidence joins to requirements by requirement id and nothing else. Every result from every tool, in every stage, cites the id it answers.
A tool-to-record contract. A verification tool emits records against a published schema and needs to know nothing about Teamcenter. Adding a tool is a mapping file, not an integration project.
A citation that resolves. Evidence that does not point at a re-fetchable managed object is rejected rather than accepted quietly, which is what makes the readiness number auditable instead of merely computed.
Open interchange. ReqIF for requirements, STEP and JT for geometry, FMI and FMU for behavioural models, OSLC for linked lifecycle data.

Deliberate, and worth saying out loud in the room. The system model in stage 0 is authored in a competitor's tool and the thread carries it regardless. An authoritative source of truth that only accepts its own vendor's authoring tool is not an authoritative source of truth. It is a silo with better marketing.

6Measured, not asserted

Every claim below is a real run, against the real article, with a result the customer can open and re-check, not a capability slide.

Claim	Evidence
Thermal verification of the MSP-2 card, on Simcenter Flotherm 2604	RUN 110.12 °C measured, real solver, converged in 410 of 1500 iterations
Functional coverage and formal verification of the MSP-2 datapath, on Questa Sim-64 2026.2	RUN real report files
Headless hardware and software twin, on Innexis Architect Explorer 2026.1	RUN licensed, ran, measured
Requirements, both candidate architectures, the mission layer and the readiness metrics as native Teamcenter objects	RUN Teamcenter 2606, read back from the tier
Hardware and software co-analysis on a SystemC/TLM virtual platform against the unmodified MSP-2 RTL, Questa Sim-64 2026.2	RUN 2.500000 GSPS, 0 ICD deviations over 23 checks, with defect runs that failed as they should
Reduced-order modelling toolchain, Simcenter romAI	RUN 4 ROMs trained, 4 FMI 2.0 FMUs exported and stepped, and every one fits worse than a constant predictor on held-out data while the concept model reproduces it exactly. Both halves belong together

And the portfolio rows above that did not run here, said plainly. Innexis Virtual System Interconnect is installed and will not license (a certificate format, not an entitlement). Capital's interface bundles validate and generate, but the import step needs the Capital GUI and no Capital licence checkout was demonstrated. HyperLynx and Simcenter 3D are not installed, so the multi-mode column is shown one technique wide. Veloce is emulation hardware rather than an install, and it is the incumbent's ground. The full split is on the Positioning page.