System-MDAO: finding the best answer for the whole program

System-MDAO (S-MDAO) is an approach we are building for chief engineers. It uses Siemens HEEDS, with Teamcenter as the place every input comes from and every result goes back to. This page explains what it is, what we proved this week, what we learned, and what we expect when it grows to the size of a real program. No mathematics is needed to read it.

What S-MDAO is for

A large program is designed by many engineering teams at once: structures, propulsion, power, electrical, cost, supply chain and more. Each team's work depends on numbers from other teams. S-MDAO takes in far more of that digital information than was historically available, and searches for the design that is best for the whole system.

Two points shape how we use it:

• The system model says what is expected. It does not say which design is best. Many designs can meet the requirements. S-MDAO's job is to find the best of them.
• A chief engineer's decisions are often not a single number. "Include this element." "Favour the supply-chain fix." "Rescue this program and give me the most honest answer." S-MDAO is meant to support those calls, not replace them.

What we proved this week

Everything below was run on our own workstation with the Siemens software, not taken from a brochure.

• The Siemens platform is installed and working. HEEDS Connect runs with our single sign-on and our licences, and studies can be built and run entirely by script, so a run can be repeated exactly.
• We reproduced Siemens' own reference answer. Siemens publishes a standard two-team test problem with a known best answer. Their project, run unchanged on our machine, found the same best design to seven significant figures. It took 3 hours 41 minutes.
• Teamcenter can hold the models and their results. The two-team study models and the result files of one of our coordinated runs are stored in Teamcenter as native simulation objects, with their input and output tables filled in, and every file checked byte for byte after upload. Siemens' reference run is not in Teamcenter yet.

The key finding: when every team optimises for itself, the system loses

We also ran the same test problem a second way, the way most programs actually work: each team is given its own goal and its own share of the problem, and a coordinator tries to make their numbers agree.

Setup	Who decides what "best" means	Result
One system goal (Siemens' approach)	The system as a whole	Found the best design
Each team optimises its own goal	Each team separately	Settled on a design 11 to 13 times worse than the best

We ran the second setup eight times, changing every setting that seemed a plausible cause. Every run started close to the best design and then drifted away from it. The final designs were not errors in the usual sense: every team's numbers agreed with every other team's. The answer looked finished and consistent. It was simply a bad answer for the system.

The reason is simple to state. One team had no goal of its own beyond agreeing with the others. Another team did not care about one of the values it controlled. Nothing in the process defended the system's interest, so agreement was reached at the wrong place.

What this means for a chief engineer: with fifteen or more disciplines each optimising their own choices, agreement between teams is not evidence that the program has found a good design. S-MDAO keeps a single system goal at the top for exactly this reason.

The next question: what happens at the size of a real program?

Programs describe who needs what from whom in a grid called an N2 chart. Every row and every column is one piece of the design. A mark in a cell means "this piece needs information from that piece."

The order of the rows matters. If a piece only needs information from pieces above it, the work flows downhill in one pass. Every mark that points back up the grid is a loop: work that must be revisited once later results arrive, like a drawing that has to be redone after a supplier changes a dimension.

Our test problem is a 2 by 2 grid. An aircraft carrier is a grid of about 10,000 by 10,000, and even that is a simplified, representative view. We had no real program grid to hand, so we built realistic stand-ins on the computer: 81 grids of 1,000, 5,000 and 10,000 pieces, some loosely and some tightly connected, and worked each one through in four different orders. We also put a system goal on top and checked which design a program would actually choose. These runs did not use the Siemens tools yet.

What we measured at carrier scale

• Growing the grid to 10,000 pieces did not change the outcome. A program of 10,000 pieces needed about the same number of design cycles as one of 1,000 (around 18 in the looser grids), and reached equally good designs. Each cycle is ten times more work, but the program does not need more of them. What changed every result was how tightly the pieces depend on each other, not how many there are.
• Most of the program ends up in one big loop. Once each piece depends on four or more others, about 95% of all pieces sit in a single loop where everything affects everything else, at every size we tried. Good ordering cannot break that loop, but it still removed half to nine-tenths of the backward marks, in a few seconds of computer time.
• Order matters when there is little time between decisions. When the program could only work the grid through once before each design decision, a good order captured up to 26 points more of the achievable improvement than a bad one. Given five or more passes per decision, every order reached an equally good design.
• In tightly connected programs, the order can pick the answer. In one 10,000-piece grid there were two different designs that every piece fully agreed with. Working the grid in one order settled on the first; working it in another settled on the second. Neither looked unfinished. This is the carrier-scale version of what we saw on the small test problem: agreement between teams is not proof of the right answer.
• A tightly connected program can fail to settle at all, whatever the order. A third or more of the more tightly connected grids never settled, in any order. Ordering does not fix that; it is a property of how strongly the pieces pull on each other.

What we expected and what we found:

We predicted	We found
Order changes the work, not the final answer	True when there is only one right answer. Not true when there are several
Stopping early lets order change the answer	True only when very little work is done between decisions
A bad order may never settle	Not supported: settling depends on how tightly connected the program is
Ordering removes most loops, not all	True at every size
The Siemens method will not stretch to this size	Not yet tested
The biggest risk is an unfinished answer that looks finished	True for tightly connected programs; loosely connected ones give an honest warning

These are measurements on realistic stand-ins, not on a real ship program. How tightly a real program's pieces are connected is the number that would decide which of these findings apply, and nobody has measured it yet.

What happens next

• Measure how tightly a real program is connected. A real N2, even a partial one from Teamcenter or a past program, would tell us which of the findings above apply to a carrier.
• Confirm on small grids with the Siemens tools, so that the full-size results can be trusted to carry over, and test whether the Siemens method stretches to this size.
• Keep Teamcenter as the source and destination, so the N2 comes from the program's own data and the answer, with how well it closed, goes back as a record the chief engineer can act on.

Status as of 28 September 2026: the platform and the Siemens reference problem are proven. The finding about team-by-team optimisation is proven on the test problem. The carrier-scale findings are measured on realistic computer-generated programs; they have not yet been checked against a real program or run in the Siemens tools.