Flight Test Execution in Teamcenter

Approach

The post-flight execution deck lays out a five-page wizard: Mission, then each Event, then Test Points, then parameters, then service data. We keep its content and drop its shape. Teamcenter users do not fill in forms that sit outside the objects. They open an object, use Edit, change fields on a tab, and Save. Tables of child data are edited inline. Status changes happen through workflow tasks, which also lock the record.

So each page of the deck becomes a tab or a table on the object that owns the data, and the wizard's Save Draft and Submit buttons become an Inbox task. The deck and the attributes spreadsheet remain the inventory of what must be captured.

Almost all of that inventory already has a home. The Catalyst template built execution on top of Verification Management: the Mission is a Verification Request, the Flight Event is a test run, and each Test Point in a Flight Event is a validation link that already carries the execution fields, including the votes.

Decisions taken

Object map

Inheritance read from the 2506 export. The Mission and the Flight Event both inherit Crt0VldnContractRevision, which is where the shared Flight Test fields xve5ExecutionState, xve5PlannedDate and crt0ValStartDate live.

flowchart LR
  M["Mission
XVE5Mission
(Verification Request)"] --> E1["Flight Event
XVE5FlightEvent
(Test Run)"]
  M --> E2["Flight Event ..."]
  M --> D["Execution Card Deck
XVE5MissCardDeck
xve5IsExecutionCard = true"]
  D --> C["Execution Test Card
XVE5TestCard
xve5ExecutedFlightEvent"]
  E1 --> R["Result row per run
Crt0ValidationLink"]
  R --> TP["Test Point
XVE5TestPoint"]
  TP --> REQ["Requirements
(verification rollup)"]
  E1 -.-> SLM["Serialized tail
SLM as-maintained"]

Execution flow

1. Mission is approved.The Test Card Release workflow has released the cards; the Mission and its Flight Events reach xve5ExecutionState = Approved.
2. Start Execution.The test conductor runs Start Execution on the Mission. The server builds the execution card decks and adds one result row per planned Test Point to each Flight Event. See Start Execution.
3. Post-flight task arrives.The execution workflow puts a Record post-flight data task in the Inbox of the responsible flight test engineer, one per Flight Event. A Home tile, Missions to execute, runs a saved query for anyone who prefers to start from the Mission.
4. Record the Flight Event.From the task, the engineer opens the Flight Event and fills in the Execution tab and the Test Point Results table, including any unplanned repeat runs and build-up parameters, then records service data in SLM.
5. Submit.Completing the task validates the record, sets xve5LockExecutionProp, and moves the Flight Event to Executed. When every Flight Event is Executed, the Mission task opens for the Mission-level outcome and delays.
6. Data assessment (vote 3).Each discipline engineer gets a task for the Test Points they own, reviews the data and records acceptability on the result row.
7. Grade and roll up.Event and Mission grades are derived from the result rows. Accepted Test Point results roll up to requirement verification status.

Mission page: Execution tab

A new tab on XVE5MissionRevision, shown when xve5ExecutionState is Approved or later. Fields are read-only unless the Mission task is open and the lock flag is false.

Flight Event page: Execution tab

A new tab on XVE5FlightEventRevision. Every field on page 2 of the deck and in the EVENT block of the spreadsheet exists in the model.

"Required for flights" applies when the event type is a flight. A ground test or functional checkout needs only the power times.

Flight Event page: Test Point Results tab

Two tables on the Flight Event, both edited inline.

• Test Point Results: the Verification Management results table, one row per Test Point (a Crt0ValidationLink). It holds the Test Point's final outcome for this Flight Event: vote 3, rejection reason, verification result and data files.
• Test Point Runs: a new table property xve5TPRunTbl on the Flight Event, rows of a new table-row type XVE5TPRunTable (the same mechanism as the delay tables). One row per execution: Test Point, sequence #, run type, IADS ID, start and stop time, votes 1 and 2 with their reasons, and run status. Add Repeat Run adds a row for the selected Test Point with the next sequence number and run type Repeat. This replaces "Add a Copy" in the deck.

Start Execution creates one result row and one run row per planned Test Point. In the table below, the run-level columns (sequence through run status) move from the link to the run table; the link keeps the rest.

Build-up parameters

Page 4 of the deck lists a Test Point's parameters (altitude, KCAS, gear, configuration, G, pitch rate) with min, goal and max, editable for an in-flight build-up. In Teamcenter these are the Test Point's Parameter Management values, and the build-up values are overrides in the context of the run, not edits to the released Test Point.

Users reach them from the result row with Edit Run Parameters, which opens the Parameters table for that row. The released Test Point keeps its planned values.

Service data

Page 5 of the deck records landings, engine time, electrical power-on time and gear cycles for the tail. These update the serialized aircraft in SLM, using SLM's own usage recording against the as-maintained structure for xve5AircraftID.

• Engine time defaults to engine off minus engine start; editable.
• Power-on time defaults to power off minus power on; editable.
• Landings and gear cycles are entered.

The Flight Event gets a Record Usage command that opens the SLM entry for that tail with these defaults filled in.

Start Execution

One server-side action on an approved Mission. It is the only custom code in release 1. It must be safe to run twice: a second run fills gaps and never duplicates.

1. Check.The Mission and every Flight Event are Approved; every assigned Test Card is released and not past xve5ExpDate. Otherwise stop and list what is wrong.
2. Build execution decks.For each approved Mission Card Deck, create an execution copy with xve5IsExecutionCard = true and xve5ExecutedVR pointing to the Mission.
3. Build execution cards.For each card assigned to a Flight Event, create an execution copy with xve5IsExecutionCard = true and xve5ExecutedFlightEvent pointing to that event.
4. Create result rows.For each Test Point on those cards, add a result row to the Flight Event in card order: xve5RunSeq = 1, xve5RunType from the Test Point, xve5TestCard set.
5. Start the workflow.Set the execution state and start the post-flight workflow for each Flight Event.

Workflows

The existing Test Request, Test Plan and Test Card Release workflows are unchanged.

Rules

Put these in BMIDE (conditions, property constants and a save-time check) and in the page layout's visibility conditions, so they hold for every way data gets in, including imports and the API.

• Conditional reasons. Each reason field is visible and required only when its result field is not the success value.
• Time order. Power on ≤ engine start ≤ taxi ≤ takeoff ≤ landing ≤ engine off ≤ power off. Missing times are allowed while drafting and blocked at submit.
• Derived defaults. Flight duration, Executed date and Flight date are filled on save when empty and stay editable. They are stored values, not runtime properties, so later edits stick.
• Lock. When xve5LockExecutionProp is true, execution fields are read-only for everyone except the DBA role.
• Vote order. Vote 3 can only be set on a run whose status is Executed.
• Grade derivation. Event: Successful if every executed run has vote 3 Accept, Partially Successful if some do, Non-Productive if none do. Mission: Successful if every Event is Successful, Partially Successful if at least one is, Non-Productive if none are. Canceled and Aborted are set by people, never derived.

Screen crosswalk

Where each part of the post-flight execution deck ends up.

Open questions

1. Outcome at post-flight versus grade after assessment. The deck asks for Successful, Partially Successful or Non-Productive at post-flight. The product summary defines those grades as the result of the data vote, which happens later. Proposal: at post-flight the engineer records only Flown, Aborted or Canceled, and the three grades are derived after assessment. This needs a decision before the LOV is fixed.
2. OPS #. The model has an integer; the deck and spreadsheet say alphanumeric. Changing the type of an existing property is a migration, so confirm what values are really used.
3. Run start and stop times. The model stores them as strings. Decide whether they are clock times, IADS times or offsets from takeoff.
4. Without TcQualification. The product summary leaves open what replaces qualification checks if the customer does not license it. This affects the Start Execution check, not data entry.

Checks against the 2506 tier

Run read-only on 2 Nov 2026 against the Saber 2.0 / Pre-Int 2506 tier: type descriptions plus the properties and relations of the 4 Missions, 1 Flight Event and 4 Test Cards found there. Nothing was written.