Demonstration artifacts

1Specifications

The two documents the demonstration's requirements and matrix live inside: both render as full documents in Active Workspace: numbered paragraphs, real requirement text, element tree, summary table.

Three more artefacts surface the same data on the Reports tile. Two carry real Teamcenter uids; the third (XC0_MSP2_VCRM_XT_001, the RFP Table 4-1 crosstab) is a classic report + XSL stylesheet pair rather than a single searchable object, so it is cited by report id and commit instead of a uid, full mechanism on Documents.

2Mission & operational context (Stage 0, Seg0)

3Requirements (Stage 1, all 22)

Text, criticality, applies-to and methods come from the source requirement set (readiness/data/requirements.json), carried alongside the Teamcenter object each requirement lives as.

4Logical architecture (Stage 2, root + both candidates)

5Functions

6Verification Requests (type Crt0VldnContract, all 37)

One per matrix row: a requirement crossed with the technique(s) assigned to it (DYNAMIC, STATIC, MULTI_MODE, CO_ANALYSIS, INDEPENDENT). Confirms the 37 figure on Stage 1b by direct query.

7Simulation Requests (type Crt0SimStudy, all 22)

Spawned under a parent Verification Request wherever the technique calls for one: Teamcenter enforces the parent link via a required property on the create-input, not a naming convention. Confirms the 22 figure on Stage 1b by direct query.

8Tests (type Crt0Test, all 6)

Confirms the "6 Tests" figure in the Stage 1b card by direct query rather than by repeating it.

9Readiness record attributes (Spine, all 9)

The computed fields behind the readiness table on Demonstration §1, gate, coverage, ceiling, failed/unverified counts, as real Teamcenter attribute definitions, not spreadsheet columns.

10Cameo model

The system model everything else in the demonstration is built over: mission context, functional architecture, and the logical architecture for both candidates. Not a Teamcenter object: a real file, backing item 007030 in Teamcenter.

7 mission elements, a function root with 8 functions, a logical root with Candidate A (7 blocks) and Candidate B (8 blocks), 20 Allocate dependencies, 5 authored diagrams.

11Stage 2: the trade

The Decision Management trade study behind the Candidate A / B comparison, as the files that drive it: the frozen criteria, the recorded judgments, and the decision itself.

12Stage 2b: Simcenter Flotherm

The multi-mode thermal evidence that decides Candidate A, real solver output, not a constructed number. See Demonstration §2 for the measured 110.12 °C.

13Stage 3: Questa

UVM functional coverage and formal property analysis on the MSP-2 datapath, including the real UCDB coverage database.

14Stage 3: Innexis Architect Explorer

The MSP-2 hardware/software twin, executed, including the actual compiled binary that ran on the modelled quad-core Cortex-A53.

15Stage 4: Capital

The DESIL interface check and the backplane project bundles for both candidates, plus the port-coverage gate output for this article.

16Spine: the readiness engine

The engine and its data, independent of the demonstration tier: the floor nothing else can fail beneath, and the dashboard it drives.