F-35 Lightning IIF-35 JPO Digital Engineering
Unclassified · 2026-08-15
F-35 Lightning II
Value proposition → Next Generation JPO

The partner who can close the loop the JPO already drew

One page, for a programme office that has already written down what is wrong. Siemens does not propose a different diagram. It proposes being the vendor able to complete the one the JPO published.

Unclassified throughout Siemens proposed view Fictional demonstration article

1What the JPO asked for, in its own words

The Digital Engineering Overview (Cordova / Neeld, 7 July 2025, Distribution A, JSF25-0040) states four findings. They are not a request for an emulator. They are a request for a connected programme:

A stove-piped development process. Insufficient design verification. Limited visibility into assembled hardware. Limited use of industry-standard tools and processes.

The spine under the JPO's own future-state chart reads "Digital Thread: Full Connectivity, Visibility and Authoritative Source of Truth." Every argument on this page is downstream of taking that sentence literally.

The asymmetry, in one line. A pure-EDA vendor can verify the card. Siemens can verify the card and own the authoritative record the verification has to land in, then carry it forward to flight test and through sustainment. The JPO's closed-loop slide puts PLM at the top of the loop. The vendor named on that slide does not sell PLM.

2Each finding, and what answers it

JPO findingWhat it actually requiresWhere Siemens answers it
Stove-piped development process One authoritative record that mission, requirements, architecture, electronics, mechanical, software and test all write into, rather than exchange files around. Teamcenter as system of record, with Requirements, Systems Engineering, Program Planning and Simulation Process and Data Management on the same object model. Polarion carries the software side.
Insufficient design verification Verification planned per requirement and executed across several independent techniques, not one. Questa for functional and formal, Simcenter Flotherm for thermal, HyperLynx for signal and power integrity, Simcenter 3D for vibration, Innexis for the hardware and software twin. Five techniques against one requirement set. On the demonstration article itself, thermal is the multi-mode technique that ran: see the proven and proposed split.
Limited visibility into assembled hardware A hardware-accurate model that runs the real operational flight program before metal exists, and stays connected to the record. Innexis Architect Explorer for the modelled processor running real firmware, with Questa SystemC and TLM co-simulation. Evidence returns to Teamcenter against the same requirement ids.
Limited use of industry-standard tools and processes Open interchange the government owns, and a process framework a review board already recognises. ReqIF, STEP and JT, FMI and FMU, OSLC, AUTOSAR-shaped electronics models, and ISO/IEC/IEEE 15288 as the process spine rather than a vendor method.

3Five reasons this is a Siemens problem

1. Siemens owns both ends of the loop

The JPO's closed feedback loop runs PLM, verification automation, formal analysis, coverage-driven simulation, emulation, and continuous metrics. Siemens sells the electronic design automation and the PLM, ALM, MBSE, multiphysics and service lifecycle management the loop closes into. No competitor on that slide sells more than one arc of it.

2. Breadth is the requirement, not a bonus

A mission systems processor is a thermal problem, a signal integrity problem, a software problem, a reliability problem, a manufacturing problem and a sustainment problem at the same time. A partner who answers one of those forces the programme to integrate the rest by hand, which is precisely the stove-piping the JPO already identified.

This is also where a physics-first vendor tends to move fastest and stop shortest. A demonstration that jumps to thermal, structural and CFD results can look thorough while skipping the electronics-architecture risk underneath a part swap: a monolithic-die FPGA replaced by a pin-compatible part built as a multi-die package, say, 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 before the multiphysics story even starts.

3. The government keeps the authoritative source of truth

Title 10 pressure to reduce dependence on industry is a PLM argument, not an emulation argument. It means the JPO holds the record and the primes write into it across a governed boundary, with configuration control, access control and an audit trail that belongs to the government. That is Teamcenter's home ground and it is the single hardest thing to retrofit later.

4. Readiness becomes a measurement, not an opinion

"Objective implementation readiness analysis with continuous metrics" is 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. Stated that way it stops being a dashboard request and becomes a standards obligation, which is a much stronger footing for a SETR board.

5. One thread, from concept through sustainment

The same requirement id that carries a thermal result in design carries a flight test result later, and a depot finding after that. Siemens is the only participant able to draw that line across the whole life cycle without changing vendor at each stage.

4The number is computed, and it can be audited

The demonstration does not present a readiness percentage on a slide. It computes one from verification evidence and lets the customer open the evidence. Three rules are load-bearing and each has a test that fails if the rule is removed:

  • Evidence that does not cite a re-fetchable artefact is discarded, and the discard is reported rather than hidden.
  • A requirement with no evidence is unverified. It is never interpolated and never assumed to pass.
  • When the evidence base is too thin to support a figure, the engine abstains with a stated reason instead of emitting a number.
The figure that carries the room. The JPO's own IV&V slide asserts 10–20 percent verification coverage from a single technique and 60–80 percent from several. This demonstration computes the ceiling from the verification plan and lands at 24.24 percent for simulation alone against 93.94 percent achieved with five techniques. The number moves with the requirement set, which is exactly why it is worth computing rather than quoting.

A readiness score a review board cannot audit is worse than no score at all. That principle is why the abstention case is shown first in the room, before any result that flatters the argument.

5Organic capability, deployable where the programme needs it

The demonstration was built and runs on a self-contained Teamcenter 2606 environment with no external dependency, which is the deployment posture the programme actually needs: on premises, capable of running disconnected, and under government configuration control. The interchange formats named above mean the JPO is not buying a cul-de-sac. A supplier who prefers a different authoring tool can still write into the record, which is the practical test of an authoritative source of truth rather than a vendor silo.

The demonstration proves this deliberately: the system model is authored in a competitor's tool and the thread carries it anyway.