Solution brief

F-35 JPO Digital Engineering: solution brief

What the JPO's Digital Engineering Overview (Cordova / Neeld, 7 July 2025, Distribution A, Approval ID JSF25-0040) asks for, what Siemens answers each ask with, and how the MSP-2 demonstration proves it on a real article rather than a slide.

---

1. The problem, in the JPO's own words

The findings behind the deck are a stove-piped development process, insufficient design verification, limited visibility into assembled hardware, and limited use of industry-standard tools and processes. The spine under the JPO's own future-state chart is "Digital Thread: Full Connectivity, Visibility and Authoritative Source of Truth."

Three consequences shape this solution.

The closed feedback loop on the JPO's own roadmap needs PLM at the top of it. That loop runs through verification-plan automation, formal analysis, coverage-driven simulation, emulation and continuous metrics. Siemens brings the electronic design automation and the PLM, ALM, MBSE and multiphysics layer the loop closes into, on one platform.

"Objective implementation readiness analysis with continuous metrics" is answered as a standards-based measurement, not a dashboard. It maps to ISO/IEC/IEEE 15288 clause 6.3.7 measurement, driven by 6.4.9 verification evidence, consumed by 6.3.2 project assessment and control. The readiness figure in this demonstration is computed from evidence the customer can open, not asserted.

"Reduces dependence on industry" is a PLM argument. Organic capability means the government holds the authoritative source of truth, with supplier and OEM writing into it across a managed boundary: Teamcenter's home ground.

2. What Siemens answers each ask with

What they asked for	Siemens answer	Clause
Hardware-accurate digital twin: early HW/SW system integration and co-development	Virtual system integration and early hardware/software co-development, underpinned by Innexis Architect Explorer / VSI, with Questa for RTL simulation and Catapult for HLS	6.4.7, 6.4.8
Comprehensive verification: continuous metric-driven assessment against implementation readiness	Continuous, metric-driven verification against every requirement: functional coverage and formal analysis (Questa), multi-mode analysis (Flotherm), and hardware/software co-analysis (Innexis), landed as evidence and rolled into a computed readiness record	6.4.9, 6.3.7, 6.3.2
Commercial best practice: modernize defense-industrial-base development and sustainment	A shared, managed source of truth across Supplier / OEM / Gov boundaries, built on Teamcenter	6.1.1, 6.1.2, 6.3.6
Verification plan automation	Verification method assignment against every requirement, generating the plan rather than authoring it by hand, in Teamcenter Systems Engineering	6.4.9 outcome a
Reduced cost / schedule through digital twins	Cost and schedule visibility, through Teamcenter Cost Rollup and Program Planning / IPP&E	6.4.6, 6.3.1

On the JPO's own IV&V techniques slide, multi-mode analysis (power, thermal, EM) and the quality system behind independent analysis are rows a pure-EDA vendor has no comparable answer to at all. Lead the technical story there.

3. The article: MSP-2

MSP-2 mission systems processor, DMSMS-driven refresh: a fictional radar signal-processing card whose primary FPGA has gone end of life. Unclassified throughout; no F-35 data of any kind is used or implied.

Chosen because it is the customer's own stated problem (DMSMS refresh), because it forces every one of the five IV&V techniques to be genuinely necessary, and because two candidates on a shared parent make the trade-study machinery real rather than a single-option walkthrough. A pin-compatible part swap also rewards this stack specifically: pin compatibility says nothing about internal die architecture, and a physics-only review is never positioned to catch that gap.

	Candidate A, pin-compatible refresh	Candidate B, SoC consolidation
Change	Drop-in replacement FPGA, same footprint	Consolidate FPGA and companion processor onto one SoC
Board impact	Minor re-spin	Substantial re-spin, new stack-up
Where it wins	Fast, cheap, low re-verification burden	Long obsolescence horizon, headroom for growth

Neither candidate is built to win. The criteria are frozen before any Stage 2b or Stage 3 evidence exists, timestamped, so the trade cannot be argued backward from the answer.

4. Stage by stage

Numbered to match the JPO's own Stage 0–6 future-state chart.

Stage 0: Mission. One mission and its phases in which the MSP-2 matters, authored on Teamcenter's Seg0 operational-analysis layer. Cameo carries the context of use and the use cases that make an obsolete FPGA a mission problem rather than a parts problem: managed through Teamcenter MBSE Integration Services, deliberately proving the thread holds a competitor's authoring tool too.

Stage 1: Requirements and verification plan. Twenty-two requirements loaded into Teamcenter Systems Engineering, each carrying its assigned verification method: this is verification plan automation, generated from the assignment rather than authored as a document.

Stage 1b: the Section 4 verification matrix. Built over Stage 1's requirements: 37 Verification Requirements, 37 typed trace links each carrying a method from Teamcenter's own vocabulary, 37 Verification Requests, 22 Simulation Requests and 6 Tests. A saved Trace Link Matrix renders the same shape an RFP Section 4 response is graded on, generated rather than typed by hand.

Stage 2: The trade. Two candidate architectures, criteria frozen and timestamped before any Stage 2b evidence exists, run through Teamcenter Decision Management with HEEDS taking the sweep.

Stage 2b: Multi-mode analysis. Candidate A fails on thermal: measured on Simcenter Flotherm 2604 at 110.12°C against a 105°C limit. Candidate B measures 100.16°C and passes. This is the column a pure-EDA competitor cannot fill at all, and only multi-mode analysis could have found the failure. Thermal is not the only way a "pin-compatible" part hides risk, though: see Stage 3.

Stage 3: Hardware-accurate twin. UVM functional coverage, formal property analysis, CDC and autocheck on Questa. System-of-systems HW/SW co-analysis runs via Questa SystemC/TLM co-simulation, with Innexis Virtual System Interconnect as the product answer at full scale. This is also the technique that catches what a footprint check cannot: real firmware run against a modelled processor, not a pin-compatibility checklist. 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. Logic 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. Architecture-aware, hardware-accurate modelling is built to catch that; a compatibility checklist is not.

Extended 2026-08-18: this stopped being narrative-only. A second twin variant (stage7-innexis-vsi/msp2-twin/src/msp2_twin_2chiplet_mgt.xml) splits Candidate A across two chiplets bound to input- and output-side transceiver banks, joined by a UCIe die-to-die link the filtered sample stream is now structurally forced to cross, not because the logic is too large for one die, but because the input and output pins are fixed to opposite package edges, which is the harder version of the claim to argue with. It validates clean against Architect Explorer's own schema, structure and logical rules both pass. Turning that validated structure into a measured pass/fail threshold is currently blocked by a hardware-generation fault in this Architect Explorer install, reproduced against Siemens' own unmodified shipped tutorial rather than this model, so it reads as a tool-install issue, not a modelling gap; evidence and repro steps are on file for whoever owns the install. Say this plainly in the room rather than let the paragraph above imply more than the demonstration currently proves: the risk is real, the model that would quantify it is built and validated, and the number is not in hand yet.

Stage 4, DESIL co-simulation. The MSP-2 twin's interface to a neighbouring subsystem, MDR-1, the mission data recorder: authored as a real interface control document: 20 signals across 32 pins, each classified safety, mission or platform. Candidate B's partition-isolation controller keeps every safety-classified net off any device that also carries mission traffic; candidate A shares three. Capital carries the modular interface architecture the JPO's own DESIL slide asks for by name.

Stage 5 & 6: HITL and flight test. Real-time execution via reduced-order models, physical testing via Simcenter Testlab and SCADAS, results returned to Teamcenter against the same requirement IDs. Sustainment and operation run on Teamcenter Service Lifecycle Management and its Xcelerator portfolio siblings.

Spine: the readiness record. Every stage writes evidence against a requirement ID. The engine computes the record and lands it in Teamcenter as the artefact a SETR gate reads, surfaced through Power BI as a continuous-metrics cockpit.

5. Where Siemens wins

The thread has somewhere to land. The JPO's own closed-loop slide needs PLM at the top of it. Siemens sells that, and the EDA under it.

Multi-mode analysis. Power, thermal, EM and structural, from one vendor, managed as evidence rather than files.

Electronics depth before the physics story starts. A demonstration that jumps straight to thermal, structural and CFD results can look thorough while skipping the architecture-level risk underneath a part swap: a monolithic-die FPGA replaced by a pin-compatible part built as a multi-die package, where the vendor's own implementation tools silently partition oversized logic across die and introduce inter-die latency no physics tool would ever be asked to find. Siemens leads with electronics because Siemens sells electronics: Questa and Innexis Architect Explorer carry that depth first.

Readiness computed against a published standard. Clause citations, evidence that re-fetches, and abstention where evidence is genuinely missing rather than a confident guess.

The Supplier | OEM | Gov boundary. Multi-site, access-controlled, government-held source of truth: the Title 10 answer, and it is PLM work.

Mission-level and airframe-level reach. Stores separation, structural life, mission modelling: ground a point EDA vendor cannot cover at all.

The thread holds tools it doesn't sell. Cameo is a Dassault Systèmes product, on the tier and managed through Teamcenter MBSE Integration Services. A thread that only works when every tool is Siemens is a lock-in, not a thread: this demonstration proves the opposite deliberately.

6. What we ask for next

1. Stores separation and structural life on Millennium 1. Simcenter STAR-CCM+ and Simcenter 3D against a workload already described and already funded.
2. One REMEDE subsystem, instrumented end to end, with readiness computed against the standard and landed in PLM: the pilot this demonstration is a model of.
3. A scoped study extending validation traceability and software-version configuration, tied to Stage 5 and 6.
4. Siemens Government Technologies engagement on the accreditation path for the JPO Cloud and AFRL HPC environment.