Demonstration outline
Numbered to match the JPO's own future-state chart, because they will recognise their own roadmap. Each stage says what gets built, what tool actually ran, and what evidence it produces for the readiness record.
1The floor: what already runs, unconditionally
The readiness engine is complete, tested, and independent of the demonstration tier. Current output on the demonstration data:
| Candidate A (part swap) | Candidate B (SoC consolidation) | |
|---|---|---|
| Gate | NOT READY | CONDITIONAL |
| Readiness | 79.6% | 88.2% |
| Coverage achieved, all five techniques | 93.9% | 91.7% |
| Ceiling for dynamic simulation alone | 24.2% | 22.2% |
| Failed / Unverified | 2 / 1 | 0 / 2 |
The ceiling row is the JPO's own claim, computed rather than quoted: their IV&V slide asserts 10–20% for one technique alone. This engine computes the actual ceiling from the verification plan and lands at ~24%, against ~94% achieved with five techniques — the number moves with the requirement set, which is why it is worth computing instead of repeating.
2Stage build
Stage 0 — Mission (clause 6.4.1, 6.4.2)
One mission and two or three phases in which the MSP-2 matters, authored on Teamcenter's Seg0 operational-analysis layer, not shadowed in Cameo. Cameo carries the context of use and the use cases that make an obsolete FPGA a mission problem rather than a parts problem — deliberately shown managed through MBSE Integration Services, a competitor's authoring tool the thread holds anyway, said out loud.
Stage 1 — Requirements & verification plan (6.4.3, 6.4.9a)
Twenty-two requirements loaded into Teamcenter Systems Engineering. Verification methods assigned per requirement — this is "verification plan automation" from the JPO's own REMEDE projects slide: the plan is generated from the assignment, not authored as a document. This stage is the denominator of every coverage figure downstream.
Stage 2 — The trade (6.3.3, 6.4.6)
Two candidate architectures, criteria frozen before any Stage 2b evidence exists, timestamped visibly. Run through Teamcenter Decision Management, HEEDS taking the sweep. The freeze is drafted by the account team, not elicited from JPO stakeholders — the file says so, and the run prints it, so nobody can show the weights without the qualifier.
Stage 2b — Multi-mode analysis (6.4.6) — lead here, not with emulation
HyperLynx (SI/PI/EMI) and Simcenter 3D (vibration) are proposed for this row and were not run against this article — said plainly rather than skipped past. This is the column a pure-EDA competitor cannot fill at all.
Stage 3 — Hardware-accurate twin (6.4.7, 6.4.8, 6.4.9)
Questa: UVM functional coverage, formal property analysis, CDC, autocheck — all exercised on Questa Sim-64 2026.2. For HW/SW co-analysis, Innexis Virtual System Interconnect is the product answer and its standalone build is license-blocked here (SALT client rejects this site's certificate); what actually ran is Questa SystemC/TLM co-simulation, demonstrating the same technique with the tool that is present. Emulation is treated as one technique of five, not the headline — the incumbent owns this slot today and the argument is not won here.
Stage 4 — DESIL co-simulation (6.4.8)
The MSP-2 twin linked to one neighbouring subsystem twin so the interface is real; Capital carries the modular interface architecture their DESIL slide asks for by name.
Stage 5 & 6 — HITL and flight test (6.4.11, 6.4.12 — gaps)
Proposed: Simcenter reduced-order models for real-time execution, Testlab and SCADAS on the physical side, results returned to Teamcenter against the same requirement ids. Stated plainly in the room: 6.4.10–6.4.13 have no confirmed Teamcenter module — a roadmap conversation, not a capability claim.
Spine — the readiness record (6.3.7, 6.3.2)
Every stage writes evidence against a requirement id; the engine computes the record. It lands in Teamcenter as the artefact a SETR gate reads, surfaced through Power BI as the "continuous metrics" cockpit — re-run live after Stage 2b lands, so the audience watches the gate move from NOT ASSESSED to NOT READY on evidence generated in front of them.
3Innexis Architect Explorer, measured
The electronics-fidelity layer between Teamcenter and the detailed verification tools. Run status: EXERCISED, 2026-08-14, licensed via the MGLS client (not the standalone SALT-licensed VSI build — the naming distinction matters and is stated in the room).
| Run | What happened |
|---|---|
Shipped tutorial (Simple_Example) | Ran headless under AE_Engine.exe: an SMP cluster across 4 cores, 5,358 DWARF functions loaded, all 8 runnables dispatched to their assigned cores |
| MSP-2 digital twin | Architecture in XML, behaviour in C, cross-compiled for aarch64, executed on a modelled quad-core Cortex-A53 at 1 GHz under Nucleus RTOS |
| Measured | frames=2584, accepted=9676, dropped=160, out=4838, recorded=4838 — 13 of 13 data-carrying points agree exactly with an independent reference implementation |
Full write-up, including the licensing correction that unblocked it: demos/jpo-f35/stage7-innexis-vsi/README.md in the source repository.
4Screenshot inventory
Cameo — mission & use cases
Stage 0. Context of use for the MSP-2 DMSMS problem, shown under MBSE Integration Services.
Teamcenter — requirement set
Stage 1. Twenty-two MSP-2 requirements with verification method assigned per row.
Decision Management — the trade
Stage 2. Frozen criteria timestamp and basis, ranking, sensitivity.
Flotherm — thermal plot
Stage 2b. Candidate A at 110.12 °C against the 105 °C limit, baseline and Candidate B for contrast.
Questa — coverage report
Stage 3. UVM functional coverage and formal property summary on the MSP-2 datapath.
Innexis AE — console output
Stage 3. The MSP-2 twin run: chiplet console, frame accounting, license checkout line.
Teamcenter — readiness cockpit
Spine. The gate moving from NOT ASSESSED to NOT READY, live, on the dashboard.
5The gaps, named
- Twenty-two of the thirty ISO/IEC/IEEE 15288 process skills behind this workspace have never been run against live data; they are specifications, not proven recipes.
- 6.4.10–6.4.13 (HITL through sustainment) have no Teamcenter module confirmed on four separate instruments — a roadmap item, not a capability claim.
- HyperLynx and the Simcenter 3D vibration case are proposed for this article and not yet run.
- The Stage 2 criteria weights are drafted by the account team, not elicited from JPO stakeholders. The freeze establishes that criteria were fixed before evidence, not that the weights are the customer's own priorities.