TeamcenterKnowledge

Skills

TC Traceability Matrix

Skill tc-traceability-matrix. Generate and COUNT a Teamcenter Trace Link Matrix, in Active Workspace and headlessly over SOA, including RFP Section 4 verification matrices. Covers the two ways to get an empty matrix with no error (direction is enforced, and the trace link type filter silently matches nothing), the undeclared response shape, the fact that a generated matrix is a transient view that is lost unless saved, and how a Product Configurator context makes the same matrix configurable per product variant. Use for any traceability or verification matrix, coverage figure, or "the matrix looks empty" investigation.

A matrix that renders is not a matrix that is right. Over a structure missing rows it draws a smaller grid and looks perfectly healthy. Always compare the cell count against an independent count of the links, from a different instrument.

Run status: EXERCISED on vm2606 (TC 2606) 2026-08-15. 22 rows, 37 cells, matching an independent GRM-walk count of 37. Reference implementation: se-process-skills/demos/jpo-f35/stage1b-verification-matrix/run_matrix.py.

Prerequisite that is usually the real problem

The matrix reads occurrences, not the IMAN_specification attachment relation. A specification whose requirements are only attached, never placed, produces an empty matrix while its Relations tab looks complete. Get tc-requirement-spec-content right first; most "empty matrix" investigations end there.

In Active Workspace

  1. Global search, select both structures (ctrl-click). Banner must read 2 Selected. Accepts specifications, items, folders or parameter projects.
  2. More Commands (...) > New > Generate Trace Link Matrix.
  3. Matrix Type:
    • Quick - only direct links between the two selected objects. Between two specs that is usually nothing, because the links live on their children.
    • Full-Rollup - rolls up the children. This is the one you want. Runs in the background and notifies when done.
    • Dynamic - all connections regardless of structure.
  4. The matrix opens in a NEW BROWSER TAB. ★★ This is the single most confusing thing about the feature. It does not appear in the work area you launched it from, and the "Traceability Matrix Generated" notification is a job-finished message that is not a link and reopens nothing. Looking for it in the original tab, in Newstuff, or via the notification all fail, and each failure looks like the matrix was never produced. Check your browser tabs.
  5. Press Save on the result, name it, and it becomes a real Awp0TraceabilityMatrix object you can reopen. Until then it is a transient view and navigating away discards it.

★★ Reopening a SAVED matrix, which is harder than saving it

A saved Awp0TraceabilityMatrix is not where you would look for it. Measured on vm2606 2026-08-16:

  • It lands in Newstuff, not in the work area you generated it from.
  • Global search cannot find it. Filtering the Type facet on "Trace" returns No results found, so the type is not searchable. Searching its exact name returns 8690 other things and not the matrix.
  • #/showObject?uid=... does not exist on this tier; it returns "Missing Page".

The route that works, read off the address bar after clicking through Explorer:

#/com.siemens.splm.clientfx.tcui.xrt.showObject?pageId=tc_xrt_Traceability&s_uid=<parent folder>&uid=<matrix>

pageId=tc_xrt_Navigate is accepted and rewritten to tc_xrt_Traceability for this type.

⚠ Run the control before concluding the type is the problem. #/showObject failing on the matrix looks exactly like "a traceability matrix has no summary page". The same route fails identically on a plain FOLDER, which certainly has one, and that is what proves the route was wrong rather than the type being special.

⚠ Full-Rollup runs in the BACKGROUND, so the new tab may take a while to appear. Quick Matrix renders immediately, and once both structures have occurrences a Quick Matrix over two specifications draws the full grid, so prefer Quick while iterating.

Headless, which is also how you count it

Internal-Requirementsmanagement-2012-10-RequirementsManagement/getTraceabilityMatrix

{"inputs":[{"clientId":"c1",
            "sourceLine":{"uid":"<BOMLine>"},
            "targetLine":{"uid":"<BOMLine>"},
            "filterTypes":[],
            "filterFormat":"NO_FILTER"}]}

sourceLine and targetLine are BOMLines, not objects. Get them from Cad-2019-06-StructureManagement/createOrReConfigureBOMWindows (see tc-bom-structure for that struct, every member required, NULLTAGs not omissions).

★★ Two ways to get an empty matrix with NO error

Both return output: [{"clientId": ""}] with no fault and no partial errors, which reads exactly like "this matrix has no trace links":

  1. Direction is enforced. Source must be the from side of the links. For a Section 3 x Section 4 verification matrix that is requirements as sourceLine and verification requirements as targetLine. Swap them and you get the empty body.
  2. The type filter silently matches nothing. filterTypes: ["IAV0ReqmtEBOMOccTL"] with DO_FILTER or DO_FILTER_SUBTYPE returns the empty body, while NO_FILTER over the identical lines returns the real map. The spelling the filter wants is not known. Default to NO_FILTER and do not turn the filter on until someone finds the right spelling AND proves it against a known-good count.

★ The response shape, which the XSD does not declare

output[0].traceabilityMap is a two-element structure, not a list of cells:

traceabilityMap[0]  ->  the row BOMLines            (e.g. 22 requirements)
traceabilityMap[1]  ->  a PARALLEL list of per-row cell lists

Cell count is sum(len(c) for c in traceabilityMap[1]). A first implementation walked the whole payload counting anything with a uid and returned 0, because it never reached the nested lists. Counting a structure you have not pinned is how you publish a confident wrong number.

What a good run looks like

rows                      : 22
rows with >=1 trace link  : 22     <- no uncovered requirements
TOTAL CELLS               : 37
links per row             : {1: 9, 2: 11, 3: 2}

Cross-check the 37 against a count obtained a different way, for example walking expandGRMRelationsForPrimary outward from each source requirement. Two instruments agreeing is the evidence; one instrument is a number.

Product Configurator: the matrix and the configurator are the same thing

CreateWindowsInfo3 carries a configContext member alongside the revision rule, and getOccurrences4's config carries variantRules. So the configurator is not a second feature bolted onto the matrix: it is the configuration of the window the matrix is computed over.

Open both structure windows with a configurator context and a variant rule, regenerate, and the matrix redraws over the configured lines. Run run_matrix.py --config-context <id> once per variant; the cell counts must differ, and the difference must match the variant conditions you wrote. A matrix that merely looks different is not evidence that filtering happened.

Variant conditions attach to occurrences (select occurrences > Variant Conditions tab), which is the second reason a folder-based matrix is a dead end: a folder has members, not occurrences, so it can never be variant-configured. Set them with InternalConfigurator-2015-10-ConfiguratorManagement/setVariantExpressions.

⚠ A child with no variant condition shows regardless of the applied variant. That is the correct default for version-independent rows, and it also means "the row is still there" is not proof your condition works. Prove it with a row that should disappear.

The VCRM is a different artefact, and the shipped LOV is built for it

A Verification Cross Reference Matrix (MIL-STD "Table 4-1") is not the trace link matrix. Both are wanted and neither substitutes:

Trace Link Matrix VCRM
columns the verification requirements a FIXED method vocabulary, N I A g f L G F
cells link counts X
role the evidence that the claim is real the deliverable that goes in the proposal

★★ IAV0VerifMethodLOV is already a VCRM legend. Six of the eight columns map to a shipped value exactly: N/A, Inspection, Analysis, Lab Test, Ground Test, Flight Test. Not a coincidence, since iav0verificationmanagement is the aerospace certification module. Choose verification methods FROM the legend when you assign them, or the VCRM cannot be populated later without re-doing the assignment.

⚠ g (ground demonstration) and f (flight demonstration) BOTH map to the single shipped value Demo. Populating both needs two site LOV values or the flavour on the method description. This is the only place the vocabulary is short of the legend.

Assign per requirement, not per technique. A blanket technique-to-method map collapses the columns and produces a VCRM that is technically correct and says nothing. A 15-year supplier availability horizon is verified by INSPECTION of a written commitment; random vibration survival is a LAB TEST because no model settles solder joint life. That per-requirement judgement is the difference between a lookup table and a verification plan.

★ State why an empty column is empty. An unmarked column is either a decision or a gap and they look identical. Record the reason next to the mapping and print it with the matrix, so "no flight test rows" reads as scope rather than as an omission.

Related

tc-requirement-spec-content (the prerequisite), tc-bom-structure, tc-relations-traceability, tc-capture-awc-calls, diagnose-silent-failure.

Generated from skills/tc-traceability-matrix/SKILL.md in the tc-automation-skills library, which is the canonical copy and also serves as the agent skill set for Teamcenter work.