Demonstration outline

1The floor: what already runs, unconditionally

The readiness engine is complete, tested, and independent of the demonstration tier. Current output on the demonstration data:

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 1b: the Section 4 verification matrix (6.4.9)

A government RFP's Section 4 is a verification matrix, and Teamcenter ships no such object: the phrase does not appear anywhere in the 2506 or 2606 documentation set. Every part of one is already there under other names, in the verification management template installed on the demonstration tier, and it is now on screen in three different shapes, not just readable from the database.

The request hierarchy is not a naming convention: Teamcenter refuses to create a Simulation Request that is not under a Verification Request, enforced by a required property on the create-input (crt0ParentVldnContract). Confirmed live rather than asserted: the demonstration tier reads back 37 / 22 / 6 across all three request types. Every one of those objects, with a deep link and its own row, is on the Artifacts page.

The requirements and verification requirements are real Teamcenter objects, read back live, each carrying its verification method, Analysis, Simulation, Test, and so on, from Teamcenter's own vocabulary. Both specifications render as real documents in Active Workspace: numbered paragraphs, element tree, summary table.

Three Reports-tile deliverables, three different shapes

The crosstab had to be a classic report, not an Active Workspace one: an AW report definition can only declare columns, and grouping by verification method needs Awp0SearchCanFilter on iav0VerifMethodCmp, which is false (measured with a real-property and a fake-property control, not assumed). A classic report sidesteps the question: it hands the engine a PLMXML document and lets an XSL stylesheet decide the shape. That is also why the flat register's Description column truncates and cannot be widened: a limit of the Active Workspace report type, not a data problem.

Column totals on the MSP-2 crosstab: Analysis 13, Independent 10, Multi-mode 7, Test 3, CO_ANALYSIS 3, every requirement covered. The report carries an Add to Dashboard command, already used to surface this matrix on the readiness cockpit.

Stage 2: The trade (6.3.3, 6.4.6)

Two candidate architectures, criteria frozen before any Stage 2b evidence exists, timestamped visibly. A formal trade study, run in Teamcenter Decision Management, with criteria and weights recorded and time-stamped ahead of the evidence, so the trade cannot be argued backward from the answer.

Two qualifiers that get said out loud at the moment the criteria go on screen. The weights were drafted by the account team and are not elicited from JPO stakeholders: the frozen file records that as its own basis field and every checker run prints it. And the trade's own result is CONTESTED, because six of the eight criteria abstained rather than score on inputs they did not have. HEEDS is not installed here, so the trade runs without a design-space sweep.

Stage 2, the architecture occurrence layer: the rollup a customer actually sees

Having a parent means two independent things in Teamcenter, and having one of them looks exactly like success. A GRM relation drives the Relations tab. Occurrences drive the Content tab, the Documentation panel, ReqIF and Word export, the trace link matrix, variant conditions and Product Configurator. An object can be perfectly parented by relation with zero occurrences: every relation-side reader returns everything, every occurrence-side reader returns nothing, and no error is raised anywhere.

The missing parent was authored rather than assumed: MSP2-FN-ROOT, "MSP-2 Mission Systems Processor Functions", Functionality item 007025. The eight functions had carried Seg0Allocate only, which points at the realising block and is an allocation rather than a decomposition, so it never gave them a parent. They now hang off the root by relation and by occurrence.

Two honest notes on this stage. The logical-block structure exists but does not render a Content tab, because a custom summary stylesheet is registered for that type on this tier and it carries no Content page: a stylesheet question, not a data question, settled by reading the preference with a known-fake control rather than by trying URLs. And Product Configurator still cannot filter the MSP-2 by software version: variant conditions are refused on a Logical Block with the same fault code as on a Requirement, confirmed with three controls in the same pass, so the refusal is a verdict about the type rather than about the formula. No product structure was invented to make a configurator demo work.

Stage 2b: Multi-mode analysis (6.4.6), lead here, not with emulation

Thermal is the technique that closes on this article; HyperLynx (SI/PI/EMI) and Simcenter 3D (vibration) extend the same multi-mode column for signal, power and structural analysis. This is the column a pure-EDA competitor cannot fill at all. Say the width of it honestly: neither HyperLynx nor Simcenter 3D is installed on the demonstration machine, so the strongest column is shown one technique wide rather than three, and the vibration requirement is deliberately left unverified in the demonstration data.

That 110.12 °C corrected this demonstration's own figure. Until the solver ran, the plan carried 111.8 °C with a margin of −6.8, which was constructed sample data. The baseline and Candidate A ran 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. The conclusion survived the solver and the slide did not, which is the outcome this demonstration was built to be capable of.

Stage 3: Hardware-accurate twin (6.4.7, 6.4.8, 6.4.9)

UVM functional coverage, formal property analysis, CDC, and autocheck, all exercised on Questa Sim-64 2026.2. Emulation is treated as one technique of five, not the headline: multi-mode analysis is where this stack answers a question emulation alone cannot. Veloce is the Siemens emulation product and is not what is shown here, because emulation hardware is a rack rather than an install and none was available to this build.

This superseded an earlier DPI-C route, whose numbers are real and are not withdrawn. Both are kept on disk because the sequence is the lesson: SystemC was reported unusable here, correctly, for exactly as long as the Siemens-distributed gcc 7.4 package was missing. Nothing about the SystemC libraries changed; the compiler they are built against arrived, and sccom then found it by itself.

Innexis Virtual System Interconnect is the product answer for system-of-systems virtual integration at scale, and it is what we would propose rather than what we ran. The standalone VSI 2026.2 tree is installed on the demonstration machine and will not license: the checkout resolves to a bundle feature the machine holds and is then refused because the certificate carries SIGN2= and not SIGN=. The blocker is a certificate format, not an entitlement, which means a re-issued licence rather than a purchase. It produced nothing here and nothing here is labelled as its output. The Architect Explorer half of Innexis is a different story, and it ran: see section 3.

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 pin-compatible FPGA can carry a different internal die architecture than the part it replaces: a documented risk elsewhere in the industry when a monolithic die is replaced by a multi-die package with less inter-die bandwidth than the original fabric. Architecture-aware, hardware-accurate modelling is built to catch that; a compatibility checklist is not. Updated 2026-08-18: a two-chiplet variant binding Candidate A's input and output transceivers to opposite die is authored and validated against Architect Explorer's schema; the measured pass/fail threshold is blocked on a hardware-generation fault in this tool install (reproduced against Siemens' own shipped tutorial), evidenced and handed to the install owner, not on the model.

Stage 4: DESIL modular interface (6.4.8)

The MSP-2 twin linked to one neighbouring subsystem twin so the interface is real: the modular interface architecture their DESIL slide asks for by name, authored as Capital exchange-format bundles. The neighbour is MDR-1, the mission data recorder in chassis slot 7, and the medium between them is the mission systems chassis backplane. The legacy interface control document carries 20 signals across 32 pins on two connectors, each signal classified safety, mission or platform. Per candidate the bundle carries 7 components, 92 ports, 20 signals, 46 pathways, 46 carriers and 6 networks, every pathway carrying its signal.

Be honest about what Capital did here, because the wording matters in the room. Stage 4 is authored and validated, not materialized in the application. Capital's own validator returns ok: true on both bundles and names both injected defects on a deliberately broken copy; the project XML is generated and its content checked element by element; the bridge serves it over the exact contract Capital's own import plugin speaks, and a control proves the readback is project-matched rather than "returns whatever is staged". The remaining step is Files › Import Project in the Capital GUI, and a Capital licence checkout was never demonstrated on this machine. Do not imply a rendered diagram.

Three evidence records reached the readiness engine from this stage, and one of them is inconclusive by construction: interface segregation is a necessary condition for the safety-partition requirement and not a sufficient one, because two of candidate B's partitions sit on a single die and "no shared writable state" is a memory-architecture question an interface model cannot reach. No co_analysis record was emitted, deliberately: an interface was defined, nothing was co-simulated, and labelling it otherwise would have moved a category that has not earned it.

The model maturity ladder (not a JPO stage: the rung their roadmap is missing)

Their chart treats a digital twin as something you either have or do not have, arriving at Stage 2. A model is not binary, it matures, and the expensive mistake is starting at the rung that costs the most. The rungs answer different questions, so "which is best" is the wrong question.

Capture and replay: the requirements defect nobody would have found

A testbench instantiating the unmodified RTL wrote down one row per sample clock, 1538 rows covering nominal collection, a saturating burst, a backpressure event, a degrade to three channels and a recovery. That captured stimulus was then replayed into the concept model.

Neither side is wrong on this evidence, and that is the point to make. The requirement never states what the decimation phase should do across a refused sample. Two engineers made two defensible choices, both models pass their own tests, and the aggregate counts agree, so nothing in the process would have caught it. This is a requirements defect surfaced by comparing artefacts, in one run, instead of in an integration lab in year three. The concept model was not tuned to match: it still defaults to the concept-level answer, and the comparator carries a control (detuned filter taps report 2670 mismatches) so it demonstrably can disagree.

The reduced-order rung: Simcenter romAI ran, and the ROM fits badly

The reason is not a tooling defect. This datapath is a four-tap filter with a decimator and a saturating 14-bit rail: exactly computable, discrete and cheap, which is the wrong shape of article for a neural continuous-time surrogate. The same tool fits the shipped continuous-physics demo to five nines. A ROM earns its place where the solver is expensive and the dynamics are continuous, and this is not that. Saying so is worth more in front of this audience than a demonstration that hides its holdout.

Two limits to keep visible: only FMI export was exercised, so ONNX, C code, DLL and Amesim submodel export are not claimed; and the exported FMU was never tested on a machine without the training licence, so nothing is said either way about handing it to a customer.

Stage 5 & 6: HITL and flight test (6.4.11, 6.4.12)

Real-time execution via reduced-order models (Simcenter romAI, whose toolchain is demonstrated above and whose fit on this article is not), physical-side testing via Testlab and SCADAS, results returned to Teamcenter against the same requirement ids. Sustainment and operation are covered by Teamcenter SLM plus its Xcelerator portfolio siblings (Opcenter Maintenance Execution, Insights Hub, Capital Publisher): a portfolio claim, not a Teamcenter-alone one, and the wording matters.

Validation is partial, and it is named as partial. Verification Management's method breadth is confirmed live on the tier and spans unit test through flight test across 37 objects. What is not yet closed is the trace: the typed trace link restricts its primary side to the verification family and never a base stakeholder-level requirement, so the 37 rows trace to the system requirements specification and not yet to the stakeholder-level one that the standard draws the validation line on. That is one relation short of settled, and it is a scoped follow-on rather than a missing capability. Do not describe it as closed.

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.

3Electronics-fidelity twin, measured (Innexis Architect Explorer)

The electronics-fidelity layer between Teamcenter and the detailed verification tools. Run status: EXERCISED, 2026-08-14, licensed and measured. The licence VelSysExplorer was checked out and logged by the tool itself.

What this run does not claim. Our own MSP-2 FMU has never been executed by any Innexis component: the FMI master route exists in the install and the FMU load itself fails. The record and replay commands belong to the standalone tree and were never exercised. The twin's flight program is a stand-in, not a delivered OFP. And no readiness number moved because of it, re-measured after the run rather than assumed.

Full write-up on the Documents page.

4The readiness record, measured

Section 1 is the engine's output on the demonstration data set, which is what the room sees run end to end. This section is the other number, and the two must not be conflated: it is the record computed from the real evidence generated by the tool runs above, and it is a much thinner record, because only some of the five techniques have a tool that runs on this machine.

The refusal to move is a feature, and it is worth stating out loud. Adding a second co-simulation tool did not move the coverage number: measured three ways, with the DPI-C evidence, with the SystemC/TLM virtual platform evidence, and with both, all three give technique coverage 21.2%, co_analysis 3 of 6 and gate NOT ASSESSED. Coverage counts requirement-and-technique pairs, and both tools answer the same three requirements. Neither did the Innexis Architect Explorer run move it, nor the romAI ROMs, because neither is verification evidence and neither was recorded as such.

The residue stays visible. Of the seven requirements that plan co_analysis, three are closed, two are inconclusive because their content is a real-time duration and RTL co-simulation runs at simulation speed (a physical limit, not a tooling gap, and no budget moves it), one has no record at all, and one is candidate B only. The requirement that was called out in advance as unreachable was: a behavioural model cannot demonstrate that an unmodified legacy binary executes, so nothing was attempted and nothing is claimed.

One finding handed to the engine's owner rather than fixed here: technique coverage counts a record as evidence for a planned technique regardless of its result, so an inconclusive record raises coverage while correctly failing to raise the verdict. That may be intended, but the report labels the row "Achieved", which reads stronger than "attempted".

5The evidence, inside Teamcenter

The argument this demonstration makes is that a readiness figure is only worth having if it can be audited. That obliges us to put the evidence where an auditor can reach it, not in a folder on a laptop. Run status: EXERCISED, 2026-08-20, on the demonstration tier.

Read from the side a reviewer actually travels: opening VR-MSP2-SR-001-DYNAMIC lists its four Questa evidence datasets by name. That is the loop closing, and it is the difference between a number and an audit.

A trap worth naming, because it nearly produced a false green. A dataset can name a file and hold nothing. Five of nine upload shapes returned success, committed with no errors, and produced a dataset naming the right file, while the storage volume answered 404 VOLUME_FILE_NOT_FOUND. The reference list is written by the commit, not by the transfer. Only fetching the bytes back separates the two, which is why every figure above is a hash of bytes that made the round trip.

Still open, and not smoothed over: three passing Questa results have nowhere to hang, because MSP2-SR-001, -013 and -022 have no static-analysis row in the verification matrix. That is a gap in the matrix rather than in the evidence, and no object was invented to hide it.

6Screenshot inventory