Siemens internal → not for the customer-facing pages

Internal analysis

Gaps, caveats, provenance detail, and self-QA notes pulled off the customer-facing pages so those pages read as a capability story, not a completeness audit. Nothing here is a capability claim to JPO: it is the honest working-note layer behind the claims that are made publicly.

·About this page

Not yet access-controlled. This page is reachable by anyone with the URL today: there is no login gate in front of it. It is separated from the public nav's visual weight and marked noindex so it will not surface in search, but treat it as Siemens-internal by convention only until a real auth gate is built in front of /internal.

Every entry below names the public page it was pulled from, so a reader can trace a claim back to its full evidentiary basis, or restore it if a section is later judged safe to re-publish.

from /

1Positioning

Product-naming QA flag

Before this reaches a slide. Every Siemens product name on the positioning page is the author's product knowledge, not independently verified against current release naming: naming has churned recently in the EDA portfolio. Confirm the product column against current release naming before any of this goes in front of the customer.

Full provenance table (proven vs. proposed)

The public page now carries only the exercised, positive evidence rows under "Evidence, not assertions." The complete table, including blocked/partial/not-run items, is preserved here:

Claim	Status
Thermal verification of the MSP-2 card, on Simcenter Flotherm 2604	EXERCISED: 110.12 °C measured, real solver
Functional coverage and formal verification of the MSP-2 datapath, on Questa Sim-64 2026.2	EXERCISED, real report files
Headless hardware/software twin of the MSP-2, on Innexis Architect Explorer 2026.1	EXERCISED: licensed, ran, measured
System-of-systems virtual integration, on Innexis Virtual System Interconnect (standalone build)	BLOCKED: SALT license client rejects this site's certificate; named honestly rather than hidden
Reduced-order modelling on this article, via Simcenter romAI	EXERCISED licensed 2026-08-15; 4 ROMs trained, 4 FMI 2.0 FMUs exported and each stepped 1538 times. Both halves or neither: every ROM scores worse than a constant predictor on a held-out block, while the stage 6 Python concept model reproduces the same holdout bit-exactly. Only FMI export was exercised; ONNX, C, DLL and Amesim submodel export were not
Signal/power integrity and vibration analysis on this article, via HyperLynx and Simcenter 3D	PROPOSED, NOT RUN neither is installed on the demonstration machine, so the multi-mode column is one technique wide rather than three
HW/SW co-analysis technique, via Questa SystemC/TLM virtual platform (the tool that is present, not the product answer)	EXERCISED 2.500000 GSPS, 0 ICD deviations over 23 checks, 5 in-run controls fired, 2 defect runs failed MSP2-SR-010. Superseded an earlier DPI-C article whose numbers stand and are kept on disk
The capture-replay finding (illustrative, not verification evidence)	EXERCISED 1233 of 2712 outputs disagreed between the RTL trace and the concept model, over one unspecified assumption about decimation phase across a refused sample; changing that single assumption gives 0 of 2712, with a detuned-taps control that fires
Architecture rollup in both carriers (relation and occurrence)	EXERCISED 25 occurrence children across 6 parents, counted from a second process with its own login; new function root `MSP2-FN-ROOT`, item 007025. Still open: no Content tab on the logical block type (a registered stylesheet with no Content page), and Product Configurator refuses variant conditions on a Logical Block, with three controls proving it is a type verdict
DESIL modular interface, via Capital 2512	AUTHORED, NOT MATERIALIZED bundles validate (`ok: true`, and a known-bad copy returns `ok: false` naming both defects), XML generated and content-checked, bridge readback project-matched with a control. `Files › Import Project` needs the GUI; no Capital licence checkout was demonstrated
The readiness record on real evidence alone	ABSTAINS coverage 24.2% with the Capital records (21.2% on Questa alone), `co_analysis` 3 of 6, gate NOT ASSESSED, under the declared 25% floor. Adding a second co-simulation tool did not move it, measured three ways
Transition, operation, and sustainment coverage (6.4.10, 6.4.12, 6.4.13), in the Xcelerator portfolio	CONFIRMED: Teamcenter SLM (Service Manager, Service Planner, Service Engineering, As-Built Manager) verified live in the TC 2606 doc set; PSDM, Opcenter Maintenance Execution, Insights Hub, and Capital Publisher extend it. A portfolio claim, not a Teamcenter-alone claim.
Validation coverage (6.4.11), in Teamcenter	PARTIAL: Verification Management (iav0verificationmanagement) confirmed live on the demo tier, method LOV spanning unit test through flight test on 37 real objects. Open: whether the trace anchors to a stakeholder-level requirement or only a derived one, the line 15288 draws between verification and validation.

Say the gaps out loud in the room. This audience has commissioned reviews that found people overstating maturity. Naming what has no answer yet is the credibility move, not a liability. That is guidance for how Siemens presenters should handle questions, not public-page content.

from /value

2Value

What Siemens will not claim (was section 6)

This audience has commissioned reviews that found people overstating maturity. Naming the empty parts of the map is the credibility move for a Siemens presenter to keep in mind: it was not right as standing public-page content, and is preserved here for the presenter's own use in the room:

Clauses 6.4.10, 6.4.12 and 6.4.13, transition, operation and maintenance, are covered by Teamcenter SLM (Service Manager, Service Planner, Service Engineering, As-Built Manager), confirmed live in the same TC 2606 doc tree as core Teamcenter, plus Xcelerator portfolio siblings (Opcenter Maintenance Execution, Insights Hub, Capital Publisher). That is a portfolio claim, not a Teamcenter-alone one. Clause 6.4.11 validation is partial: Verification Management's method breadth is confirmed live, spanning unit test through flight test on 37 real objects, but the trace does not yet reach a stakeholder-level requirement, the line 15288 draws between verification and validation, one relation short of settled, not a gap. Corrected 2026-08-15.
Innexis Virtual System Interconnect is the product answer for system-of-systems virtual integration and is not running at this site. What actually runs is Questa SystemC and TLM co-simulation, which demonstrates the same technique with the tool that is present, and it is labelled as such.
The trade criteria weights were drafted by the Siemens account team, not elicited from JPO stakeholders. What the demonstration proves is that criteria were frozen before any evidence existed. It does not prove these are the customer's priorities.
Every Siemens product name in this material is pending confirmation against current release naming.

The argument this section used to make on the public page. Not that Siemens has no gaps. That Siemens is the only participant whose gaps are at the far end of the life cycle rather than at its centre, and who will tell the programme office where they are. Keep this reasoning for internal prep; it is not phrased for the customer-facing page.

from /platform

3Platform

Product-naming QA flag

Read the product names as provisional. Naming in the Siemens EDA portfolio has churned recently, and every product name on the platform page is the author's product knowledge rather than a confirmed current release name. Confirm the whole column with the Siemens SE team before any of it reaches the customer. Being wrong about a product name in front of this audience costs more than the slide is worth.

Full run/not-run table (was section 6, "What ran, and what did not")

The public page now carries only the exercised, positive rows under "Measured, not asserted." The complete table, including blocked/not-run/gap items, is preserved here. Note the last row below is stale and superseded: corrected 2026-08-15, see tc-module-map-service-life-correction: 6.4.10/6.4.12/6.4.13 are covered by Teamcenter SLM at the Xcelerator-portfolio level, not a flat gap.

Claim	Status
Thermal verification of the MSP-2 card, on Simcenter Flotherm 2604	EXERCISED 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	EXERCISED real report files
Headless hardware and software twin, on Innexis Architect Explorer 2026.1	EXERCISED licensed, ran, measured
Requirements, both candidate architectures, the mission layer and the readiness metrics as native Teamcenter objects	EXERCISED Teamcenter 2606, read back from the tier
System-of-systems virtual integration, on Innexis Virtual System Interconnect	BLOCKED the licence client rejects this site's certificate. Questa SystemC and TLM co-simulation stands in, labelled as what it is
Reduced-order modelling, signal and power integrity, vibration, on this article	PROPOSED, NOT RUN
Manufacturing, quality and sustainment stages on this article	PROPOSED, NOT RUN proven on other articles, not on the MSP-2
Hardware in the loop through sustainment, clauses 6.4.10–6.4.13, in Teamcenter	GAP, STALE superseded 2026-08-15: see correction above

Two caveats that belong in internal prep. The product names above are unconfirmed against current release naming, as stated at the top. And the demonstration data currently reaching the readiness engine is constructed sample data for every stage except thermal, functional and the twin, so the stages marked as not run contribute nothing to the computed figure rather than contributing an optimistic guess.

from /demonstration

4Demonstration

Stage 1b: method-assignment provenance

The requirements and verification requirements are real Teamcenter objects, read back live; the method each one carries, Analysis, Simulation, Test, and so on, is an account-team judgement standing in for a JPO one. The rendered report says this about itself rather than presenting the methods as customer-supplied.

Both specifications now render as real documents in Active Workspace, reversing an earlier finding that their Content tab was empty (corrected 2026-08-16).

Stage 1b: dashboard-card correction

Correction to an earlier draft of this page. Nothing established that a dashboard card for this data is blocked: that was overstated. What is actually measured is narrower: Awp0SearchCanFilter=false blocks a chart from grouping on verification method. The rendered report does carry an Add to Dashboard command, and it has been used. What nobody has checked yet is whether the resulting card shows anything useful, given the report has no thumbnail chart. Untested, not blocked.

Stage 2: criteria provenance

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: what was not run

HyperLynx (SI/PI/EMI) and Simcenter 3D (vibration) are proposed for this row and were not run against the MSP-2 article: said plainly rather than skipped past.

Stage 3: the VSI license block

Innexis Virtual System Interconnect is the product answer for system-of-systems HW/SW co-analysis; its standalone build is licence-blocked here. Corrected 2026-08-20: the cause is NOT the certificate. After the 2026-08-19 licence update the SALT client reaches the server and answers "No such feature exists"; zero Innexis features are served out of 6,104. That makes it a licence request naming specific features, not something to debug. What actually ran is the same co-analysis technique demonstrated via Questa SystemC/TLM co-simulation, the tool that is present.

Stage 5/6: what stays open

6.4.11 validation is confirmed on method breadth (Verification Management's LOV runs unit test through flight test, live on the demo tier) but not yet on whether the trace anchors to a stakeholder-level requirement rather than a derived one: that piece stays a roadmap conversation, corrected 2026-08-15 (previously written up as a flat gap across 6.4.10–6.4.13).

Readiness twin: licensing distinction

Run status EXERCISED, 2026-08-14, licensed via the MGLS client (not the standalone SALT-licensed VSI build: the naming distinction matters internally, was previously stated in the room).

Screenshot capture recipes (production methodology, not customer content)

The verification matrix. Renders in stock Active Workspace: the "nothing customised" claim holds. Exact click path for the capture pass:

Open the requirement revision → Requirements tab (lists its verification rows).
Select a row → More commands (…) → View → Existing Trace Link.
Gear → Arrange → move Verification Method and Method Description across.

For MSP2-SR-001's co-analysis row, the panel shows: Trace Link Type Requirement EBOM Occ…, Verification Method Analysis, Method Description Hardware/software co-analysis: …, with the Verification Request beside it on an Analysis Request Link. A saved arrangement named "Verification Matrix" already exists on the ed account, so the presenter does not arrange columns live.

Say this on purpose, not discover it on stage. Verification Method is not offered as a column on the Requirements tab itself: that table's columns come from the linked object, while the method lives on the link. That is why the capture goes through the Existing Trace Link view instead.

The Trace Link Matrix (the grid). Global search, select both specifications (Section 3 and Section 4, ctrl-click, banner reads 2 Selected) → More Commands (…) → New → Generate Trace Link Matrix → Matrix Type Quick.

Two things the capture pass must know, or it wastes an hour: both learned the hard way.

The matrix opens in a new browser tab. Not the work area it was launched from, not Newstuff, and the “Traceability Matrix Generated” notification is a job-finished message, not a link.
Use Quick Matrix, not Full-Rollup. Quick renders immediately; Full-Rollup runs in the background.

Press Save on the result and name it, or it is a transient view discarded on navigation.

The gaps, named (was section 5, "The 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.11 validation is confirmed on method breadth (Verification Management's LOV spans unit test through flight test, live on the demo tier, 37 real objects) but not on whether the trace anchors to a stakeholder-level requirement or only a derived one: that distinction is what 15288 actually calls validation, and it is still a roadmap item. 6.4.10, 6.4.12, and 6.4.13 are covered, but at the Xcelerator portfolio level (Teamcenter SLM/PSDM, Opcenter Maintenance Execution, Insights Hub, Capital Publisher), not by Teamcenter alone.
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.
Resolved, no longer a gap: both specification objects behind Stage 1 and Stage 1b, MSP2-SRS-01 (Section 3) and item 007017 (Section 4), were reported empty-Content-tab as of 2026-08-15. As of 2026-08-16 both render as full documents in Active Workspace: numbered paragraphs, element tree, summary table.
Product Configurator cannot filter the verification matrix by software version. setVariantExpressions returns fault 79005, “Requirement does not support the Variant Configurable Behavior,” on this tier: confirmed by calling it, not inferred. There is also no MSP-2 product structure to condition instead; a configurator context (007018) exists with an OFP Version family (v1/v2/v3) but nothing to point it at yet. Configuring software versions in and out of the matrix is not demonstrable today.
Superseded, 2026-08-16: Port Audit is now retrofit into Stage 4, the tab is deployed and every object in Teamcenter carries it, between Overview and SCFTA.
The deployed Port Audit tab renders a hardcoded snapshot, not live per-object data: a known, two-thirds-built fix, not a fresh bug. Verified by opening it on two different MSP-2 objects and getting byte-identical output: same 26 realized / 2 waived / 6 open, same commit hashes, and a "what is open" table naming InvertedFlightFuelSystem (041908) blocks on an MSP-2 object. Of the documented 3-phase plan: Phase 1 (bind the panel to the right object) is done; Phase 3 (publish real per-item data) has a working script that has simply never been run with --apply; Phase 2 (fetch instead of compile) is the actual remaining gap, needing a real module rebuild. Full phase table and evidence in the xc0coverage-module worktree (docs/LIVE_DATA_SCOPE.md, docs/HANDOFF_awc_panel_binding.md). Owned by "Build xc0coverage port audit as a proper DC module," a separate session on this workspace's roadmap.

from /script

5Run of show

What we will not claim in the room (was section 3)

Written down so nobody improvises past it under questioning.

Twenty-two of the thirty process skills behind this workspace have never been run against live data. They are specifications, said as specifications.
The Stage 2 criteria weights are ours, drafted for review, not elicited from JPO stakeholders. The same is true one stage earlier: the verification method assigned to each Stage 1b matrix row (Analysis, Simulation, Test, …) is an account-team judgement, not JPO-supplied, the requirements and verification requirements themselves are real, read-back Teamcenter objects; only the method choice is open to challenge.
Product Configurator cannot filter the verification matrix by software version. setVariantExpressions returns fault 79005 on this tier, and there is no MSP-2 product structure to condition against yet. Say it is not demonstrable today, not that it can't be done.
A dashboard card exists for the verification matrix report and has been used, but nobody has checked whether it shows anything useful: the report has no thumbnail chart. Say untested, not blocked.
Innexis Virtual System Interconnect (the standalone, SoC-scale product) has not produced any number shown today: Architect Explorer and Questa SystemC/TLM produced what's shown, and both are named as what they are, not as VSI.
6.4.10, 6.4.12, and 6.4.13 (transition, operation, sustainment) are covered in the Xcelerator portfolio: Teamcenter SLM and PSDM, plus Opcenter Maintenance Execution, Insights Hub, and Capital Publisher. That is a portfolio claim, not a single-product one. 6.4.11 (validation) is confirmed on method breadth (unit test through flight test, live on the demo tier) but not yet on the stakeholder-need referent 15288 draws the line on; that piece stays a roadmap conversation.
HyperLynx and the Simcenter 3D vibration case are proposed, not run, against this article.
No F-35 program data of any kind appears anywhere in this demonstration. MSP-2 is fictional.

Beat 84–88, original version

The gaps, named. Stage 5 and 6 (HITL through flight test) are where their money is and where the map is emptiest; Product Configurator cannot yet filter the matrix by software version (fault 79005, no MSP-2 product structure to condition against); Port Audit / Platform Schematic is not yet in this build plan even though the reconciliation gate it would answer is already proven on two other products.

Talk track and beats: second pass, tightened to the same bar

The talk track and several beats initially kept the "say the gap out loud in the room" framing on the theory that presenter dialogue is different from passive gap-listing. On review that distinction did not hold once JPO may read this page directly: tightened to match the rest of the site:

Beat 15–27 dropped "The methods are drafted, not elicited," from the list of things to say before anyone asks.
Beat 29–40 dropped "basis: drafted, not elicited" from the Stage 2 run description, and the point line "Showing the freeze and its caveat is stronger than implying the weights are the customer's."
Beat 40–55 dropped "Say plainly that HyperLynx and Simcenter 3D were not run against this article."
Beat 55–65 dropped "and say plainly it is not what just ran" (re: Innexis VSI).
Talk track, "The freeze, before the trade" dropped the second half of the quote: "And we'll say the honest half out loud: these weights were drafted by our account team, not elicited from your stakeholders. What's proven is that the criteria came before the evidence. What's not proven is that they're your priorities yet: that's next quarter's conversation."

from /collaboration

6Collaboration

Proposal-status QA flag

Read this as a proposal, because that is what it is. Both diagrams are the Siemens view of how a Next Generation JPO could be architected. Neither is JPO direction, neither reflects a programme decision, and the partner list and work split are drawn from open-source knowledge of the F-35 industrial team and need confirming with the account team before this is shown. Nothing here is derived from programme data.

"The hard parts, named": the far end of the life cycle bullet

Clauses 6.4.10, 6.4.12 and 6.4.13 (transition, operation, maintenance) are covered by Teamcenter SLM plus Xcelerator portfolio siblings: a portfolio claim, not a Teamcenter-alone one. Clause 6.4.11 validation is partial: method breadth is confirmed live, but the trace does not yet reach a stakeholder-level requirement. In this architecture that shows up as a thinner sustainment story than the design story, and closing that one trace relation is the near-term follow-on. Corrected 2026-08-15. Removed from the public page as a Siemens-capability-gap admission; the other four "hard parts" bullets (IP boundary, interface ownership, evidence provenance across orgs, classification boundaries) are genuine architecture discussion points and stayed public.

from /artifacts

7Artifacts

Artifacts.html stayed a fully transparent object/file inventory per explicit decision (JPO participates directly in shaping the demo). Only the surrounding methodology narration, corrections and cross-session references were extracted: every data table (131 Teamcenter objects, the file inventories) is untouched on the public page.

"How this page was built" (was section 1, removed entirely)

Each "Open" link uses the deep-link pattern already proven elsewhere in this workspace (harness-studio's TcSync and check-in tooling): https://siemensdc/#/com.siemens.splm.clientfx.tcui.xrt.showObject?uid=<uid>. siemensdc is an internal hostname: the links resolve only from the network vm2606 sits on.

The real type names, not a guess. This page's first pass could not find Verification Requests or Simulation Requests: four plausible type names (Crt0VerificationRequest, Crt0SimulationRequest, Crt0AnalysisRequest, Crt0VldnRequest) all returned zero. The tc-traceability-matrix skill pointed at the Verification Matrix thread's own reference script, stage1b-verification-matrix/spawn_requests.py, which names the real shipped type hierarchy: Verification Request is Crt0VldnContract, Simulation Request is Crt0SimStudy, not names anyone would have reasonably guessed. Queried directly: 37 and 22, matching the Verification Matrix thread's own counts exactly, from a different session and a different instrument.

Specs section: superseded correction

An earlier pass on this page reported an empty Content tab on both specifications; that finding is superseded as of 2026-08-16: both now render as full documents in Active Workspace.

Requirements section: open data-discrepancy flag

The source file (readiness/data/requirements.json) actually holds 24 requirements, not 22. MSP2-SR-023 (EO video stream, continuous ingest) and MSP2-SR-024 (GNSS-denial position/velocity aiding) are real entries in the source data with no matching object found in the tc_find_items pass used to build this page, not confirmed absent from Teamcenter, just not found by this query. Worth someone checking before the demo cites "twenty-two" as the total.

Cameo model section: duplicate-file and audit detail

Two copies of the model exist: the working copy at D:\CameoWorking\MSP2_Mission_Systems_Processor.mdzip (235,958 B, modified 2026-08-16 15:07, the same session that fixed a blank-diagram-label defect on 8 OpaqueAction shapes and re-verified it against the shape actually painted), and a second copy in cameo-test-models\ (236,551 B, older mtime 15:06) that is stale unless re-verified. Content audit (independent pass): 20 Allocate dependencies, 5 authored diagrams, every count checked against the raw XMI rather than the tool's own summary. Zero Ports, zero Connectors, zero Requirement stereotype applications confirmed genuinely absent, not merely unmentioned.

Trade-data section: criteria provenance

trade/criteria.yaml records basis: drafted by the account team, not elicited from stakeholders in the file itself.

Capital section: Port Audit cross-reference

The port-coverage gate output for this article is the same reusable mechanism the Port Audit finding (see demonstration.html's removed gaps section, above) says is not yet wired into Stage 4 generally.