THE MADe BRANCH

Teamcenter → MADe: the Reliability Model

The same Teamcenter read that becomes a Capital project also becomes a MADe reliability model — the EBOM, the functions, the flows, and the propagation graph that MADe's failure analysis walks. Imported live into MADe 3.9.1 through MADe's own wizard, with nothing hand-entered. The EBOM and the functions land; the propagation graph does not yet, for a reason this page pins down exactly.

MADe is the client, so we stand up the server

MADe pulls; it does not accept a file. So the deliverable is the API payload, and MADe's own Integration wizard is the importer.

The first thing to understand is why there is no ".made file generator" and never will be. A .made project is a ZIP of Java-serialized com.phm.made.* objects — verified by unzipping a real project and finding that every entry starts with the Java serialization magic bytes AC ED 00 05. It cannot be authored from outside MADe, and nothing in the product reads a foreign one.

MADe's integration surface is the MADE API, and MADe is the client: its Integration wizards connect out to an endpoint the integrator implements and pull the model over REST. So "the MADe file" is the MADE API 2.0.0 payload, and MADe's wizard is the importer.

$ node bin/forward-to-made.mjs --bundle out/live/InvertedFlightFuel.exchange.json \
      --project "Inverted Flight Fuel System" --root-item-id 041908 \
      --out out/made/InvertedFlightFuel.made.json

FORWARD_TO_MADE_OK {"project":"Inverted Flight Fuel System","rootItemId":"041908",
  "items":13,"components":12,"functionality":11,"functions":11,"flows":44,
  "flowConnections":11,"rams":0,"criticalities":0,
  "synthesizedFunctions":11,"heuristicFlowOwners":0,
  "functionsDefaultedToTaxonomy":0,"flowsDefaultedToTaxonomy":44}

What travels

Exchange	MADe	Notes
`components`	`Item`	the EBOM the whole MADe model hangs off
`structure`	`Item.children`	flat under the system root when the read carries no decomposition
`functions` + `allocations`	`Functionality.functions`	each function lands on the item it is allocated to
`ports`	`FunctionFlow` in/out flows	`flowId` IS the port id, so the wiring resolves exactly
`connections`	`FlowConnection`	the propagation graph MADe's failure analysis walks
`parameters`	`Rams`	only when the model actually carries a rate, MTTF or MTTR
`attributes` (ASIL, DAL, safety)	`Criticality`	only when the model actually says so

No invented reliability, ever A model with no reliability parameters produces no RAMS entries — not plausible-looking ones. _meta.reliabilityProvenance records, per item, which parameter and which maturity state each rate came from, or states plainly that there were none. On the Inverted Flight model that is rams: 0, and it should be, because the model carries no rates.

The taxonomy is mandatory, and the spec does not say so

MADe does not store free-text functions. It builds a function from its own taxonomy, so a Function with a null taxonomyId aborts the entire import — and the wizard says only "an unknown internal error occurred in MADE".

Always read the workspace log when a MADe wizard fails The real cause is in %USERPROFILE%\MADE\<workspace>\.metadata\.log (the Eclipse RCP log):

NullPointerException: ... FunctionTransferObject.getTaxonomyId() is null
  at com.phm.made.api.core.helper.function.FunctionHelper.addFunctionCommand

src/forward/made-taxonomy.mjs carries the taxonomy MADe ships — 54 functions and 28 flows, lifted from com.phm.made_*.jar!/environment/taxonomy/Functional/ — and places every function and flow in it:

Field	Rule
`Function.functionType` / `taxonomyId`	the function's own name, verb first: an exact alias, then a synonym, then a stem ("Wildfire_Detection" → Detect/6041, "Send_Alert_Notification" → Transmit/6016). Default is Process/6045.
`FunctionFlow.flowType`	the category, upper case: `ENERGY` / `MATERIAL` / `SIGNAL`
`FunctionFlow.flowName` / `taxonomyId`	the flow alias for the port's domain (electrical → Electrical/7003); a connector with no stated physics is Signal-Generic/7022
`FunctionFlow.displayName`	the architecture's own port name — `flowName` belongs to the taxonomy

_meta.taxonomyProvenance records how every single one was placed, and stats.functionsDefaultedToTaxonomy counts the ones that fell through.

MADe rejects 202 on a write "Error Processing 'Items'. HTTP Status Code: 202. Reason: Unknown API Response. MADE does not support this HTTP response code." The bridge originally answered PUT/PATCH with the spec's async 202 + Location: /job/{id}, exactly as documented. The real client wants a synchronous answer. Writes now return 200.

The discovery method, reusable for the next gap Point MADe's own Integration → Export Model at the bridge and read made_requests.log. MADe's own PUT body is the contract — that is how the function and flow shapes above were pinned down. Back up the project first: export auto-saves.

The import, step by step

Every screenshot below is from the live import of the Inverted Flight model on 1 August 2026.

MADe Integration menu with Import New Project highlighted — **1 ·** *Integration → Import New Project…* With no project open, that is the only enabled entry — *Import…* and the export actions need an open project.

MADe Select API Server step with the harness-bridge host and No Authentication — **2 ·** Select API Server. The host `harness-bridge (v2.0.0)` points at `http://127.0.0.1:8080` with No Authentication. Add it once with the green plus; MADe remembers it.

MADe showing harness-bridge - Authentication successful — **3 ·** Connect. *"harness-bridge — Authentication successful. Press Next to continue."*

MADe Create a New Project step listing four available systems including Inverted Flight Fuel System — **4 ·** Name the project and pick a system. Four systems are on offer because the bridge is serving four models at once — QX-250, the espresso reference, Wildfire, and Inverted Flight. The endpoint is not single-model.

MADe Select Data step with Items mandatory and Functions checked — **5 ·** Choose the data categories. *Items* is mandatory and pre-checked; *Functions* brings the flows and the propagation graph. RAMS, Criticality, Failures and Maintenance are left unchecked here because this model genuinely carries none.

MADe Imported Model tree showing all twelve components of the Inverted Flight Fuel System — **6 ·** The pull. MADe has fetched the model and lists all twelve components — CheckValve through MainFuelTank — under the system root.

MADe Current Project Explorer showing (041908) Inverted Flight Fuel System with its components — **7 ·** Drag the root into *Current Project Explorer*. Note what MADe now displays: **(041908)** Inverted Flight Fuel System. The Teamcenter item id is visible in MADe's own UI, which is the whole point of the identity hinge.

MADe Results step summarising endpoint, request method and selected data — **8 ·** Review and Finish. `Endpoint: harness-bridge - http://127.0.0.1:8080 · Request Method: Import > Snapshot · Selected Data: Items, Functions`

MADe with the imported project open showing twelve components, zero errors and zero warnings — **9 ·** Done. `Inverted Flight Fuel RAMS from TC.made`, twelve components, and the wizard reports **0 errors, 0 warnings**. Nothing typed by hand. Read the gaps section below before taking that green panel at face value — reopening the project tells a different and more useful story.

Identity, and the return leg

Every MADe id is a spec ID object, filled from Teamcenter:

{ "externalId": "041948", "source": "TEAMCENTER", "madeId": "041948",
  "name": "ElectricBoostPump",
  "metadata": { "tcItemId": "041908", "tcRevision": "-",
                "project": "Inverted Flight Fuel System" } }

externalId is the Teamcenter stable tag, and ID.metadata is the spec's own carrier for external data that MADe stores and returns on export. That is the hinge for the return leg: when MADe exports its RAMS results back to the endpoint, every number arrives already keyed to a Teamcenter object, so writing it back is an update, never a create. The write-back itself — landing MTTF, failure rate and MTTR on Teamcenter as Att0MeasurableAttribute parameters with maturity states budget / simulated / tested — is designed against the same contract this generator already reads, but is not built.

What did not travel — read this before demoing

Two things in the screenshots above are honest defects, and the tool reports both rather than hiding them.

Every function is synthesized

MADe Properties panel showing ElectricBoostPump I/O with function type Transfer and a narrative explaining it was synthesized — The tell, in MADe's own Properties panel. Function type `Transfer` (a real taxonomy placement), and the narrative: *"Synthesized interface function: the source model wires this component but allocates no function to it."*

The generator's own count says the same thing: synthesizedFunctions: 11. A component that is wired but has no allocated function would otherwise lose its wiring entirely, so it gets one interface function to hang the flows on. That is the right behaviour given the input — but the input is missing something. Teamcenter holds all 16 real functions of this model, and holds zero allocations binding them to components, because the model expresses that binding as swimlane partitions rather than «Allocate» relations. Until the allocation travels, MADe gets a correct propagation graph attached to placeholder functions instead of to BoostFuelPressure, FilterAndRegulateFuel and the rest.

Flows arrive untyped

flowsDefaultedToTaxonomy: 44 — every flow fell through to Signal-Generic/7022. The physics is not missing from Teamcenter: 22 of this model's ports are typed there via Seg0Implements, and route-from-tc.mjs reads that typing correctly. It is the occurrence-tree read used by this generator that returns interfaceId: null. Wiring the typing into the exchange bundle would turn all 44 into ENERGY / MATERIAL / SIGNAL placements with no other change.

★ Every port arrives twice, and it breaks the propagation graph

This is the most important thing on the page, and it was found by reopening the saved project rather than by trusting the wizard.

MADe Problems panel listing 55 errors: each function missing an enabled flow property, and each in and out flow reported not connected twice — The same project, reopened. MADe's own model validation reports **55 errors and 2 warnings** — and every flow error appears *twice*: `CheckValve in flow 'fuelIn.1' is not connected`, listed once for each copy of that port.

The wizard reporting "0 errors, 0 warnings" is not the same as the model being valid The wizard reports on the transfer. MADe validates the model when the project is opened. Both screenshots above are real and neither is wrong; they answer different questions. Always reopen and check the Problems panel.

The cause is exact and measurable in the payload before MADe ever sees it. A Cameo push files every block under two parents — the owning package and the composing block — so the occurrence read reaches each port twice and emits two flow objects for it, with different BOM uids:

function: CheckValve I/O
   inFlows   BOM::242192  fuelIn.1
   inFlows   BOM::242222  fuelIn.1     <- the same physical port, second occurrence path
   outFlows  BOM::242191  fuelOut.1
   outFlows  BOM::242221  fuelOut.1    <- likewise

A connection can only reference one of each pair, so most flows end up with no connection at all:

FuelControlUnit I/O          flows=8  connected=3
FuelFilter I/O               flows=4  connected=2
CheckValve I/O               flows=4  connected=0
HeaderTank I/O               flows=2  connected=0
FuelPressureSensor I/O       flows=2  connected=1
FuelQuantitySensor I/O       flows=2  connected=0
Engine I/O                   flows=2  connected=0
ElectricBoostPump I/O        flows=8  connected=2
MainFuelTank I/O             flows=2  connected=0
FuelPressureRegulator I/O    flows=4  connected=1
FlopTube I/O                 flows=6  connected=2
                            ------------------------
                            44 flows, 11 connected, 33 not

MADe's 55 errors are exactly 11 wired components × 5: one "is missing an enabled flow property" plus one "not connected" per flow. So the EBOM and the functions land correctly, and the propagation graph — the thing MADe's failure analysis actually walks — does not.

The control that proves it is the duplication, not the transform The Wildfire project, imported through the same bridge from the same generator, validates clean: 0 errors, 0 warnings, with real allocated functions carrying up to 11 named flows each. The difference is in what the Teamcenter read returns for each model, not in the mapping.

The fix is one change in the occurrence reader: dedupe ports by (owning item, port name) rather than by BOM line. The merge guard already does exactly that, and compares parents as a sorted set for the same reason — so the rule is known and proven elsewhere in the same repository.

Why these are on the page and not quietly fixed first All three are bounded, all three are understood, and all three change what a reliability engineer sees. A document that showed the green "0 errors, 0 warnings" screenshot without them would be technically true and practically misleading.

Prior proof: Wildfire

The branch was first proven on the Wildfire model on 30 July 2026 — the same bundle that produced that model's Capital XML. It landed 14 items, 11 functions, 34 flows, 11 flow connections and 0 fabricated rates, and imported into MADe 3.9.1 as 13 components with functions on the five that have them (Gimbal_Computer carrying all five with 11 flows named Scan_Parameters, Gimbal_Slew, Fire_Detected …), with 0 errors and 0 warnings. That model did carry allocations, which is how we know the allocation path itself works and the gap is upstream in the Inverted Flight model's push.

← Capital (forward)The Coverage Gate →