{"id":18845,"date":"2026-08-12T15:54:33","date_gmt":"2026-08-12T19:54:33","guid":{"rendered":"https:\/\/blogs.mathworks.com\/simulink\/?p=18845"},"modified":"2026-08-12T15:54:33","modified_gmt":"2026-08-12T19:54:33","slug":"trade-studies-with-agentic-ai-powered-mbse","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/simulink\/2026\/08\/12\/trade-studies-with-agentic-ai-powered-mbse\/","title":{"rendered":"Trade Studies with Agentic-AI-powered MBSE"},"content":{"rendered":"
<\/span><\/div>
\"\"<\/img><\/a><\/div>
Today I am happy to welcome back<\/span> <\/span>Sarah Dagen<\/span><\/a> <\/span>from<\/span> <\/span>MathWorks Consulting Services<\/span><\/a>.<\/span><\/div>
.<\/span>\"\"<\/img><\/div>
In <\/span>my previous post<\/span><\/a>, I used an agentic AI workflow to create an initial system design for an intergalactic soup factory. That first pass produced a single design based on the RFLP (Requirements-Functional-Logical-Physical) methodology. Getting <\/span>one<\/span> architecture out of an agent is nice, but real systems engineering is about choosing between <\/span>alternatives<\/span>. So, today I am revisiting the soup factory problem and using a cornerstone technique of <\/span>decision management<\/span><\/a>: running a trade study. <\/span><\/div>
Inspired by the rapid and significant updates to coding agents since my post back in April, I also tried out a different working style that directly contradicted what I had advocated for back then: I gave the agent a little guidance and let it run without much intervention. I am glad I did this, because it helps validate that my previous approach is still what I would recommend. I have some comments on this towards the end of this article. <\/span><\/div>
This is the first of two posts. This one stops at the static architecture analysis, relying on System Composer and MATLAB. The second post will add implementations in Simulink, Simscape, and Stateflow to those same System Composer architectures with behavioral models, which changes some answers below. <\/span><\/div>
You can <\/span>access the full project I built here<\/span><\/a> in a standalone repo. <\/span><\/div>
Everything in this post is the study captured at the point in the project where the three architectures existed but no behavior had been modeled yet. The project has moved on since (I\u2019ll share that in the next part of the story). I have deliberately left the baseline numbers as they stood so you can watch how the numbers move across the study. <\/span><\/div>
Here\u2019s the obligatory AI-generated image: <\/span><\/div>
<\/span>\"\"<\/img><\/div>

The setup<\/span><\/h2>
The <\/span>Simulink Agentic Toolkit<\/span><\/a> now includes skills for Model-Based Systems Engineering (MBSE), so unlike my earlier post, I didn\u2019t have to develop my own to build architectures. I did everything in this post using only the skills shipping in the Agentic Toolkit (<\/span>Release 2026.08.05<\/span><\/a>). <\/span><\/div>
I started with the same set of stakeholder needs and system requirements as last time: a facility that cooks 8 soup varieties at 200 bowls per hour, ships them across the universe by rocket, runs with at most 5 crew, and fits within budgets for mass, power, cost, and volume. <\/span><\/div>
<\/span>\"\"<\/img><\/div>
As before, I had the agent use the RFLP methodology to develop the architectures If you don\u2019t recall from the previous post, here\u2019s a reminder on what that methodology looks like:<\/span><\/div>
<\/span>\"\"<\/img><\/div>

Three ways to build a soup factory<\/span><\/h2>
Based on the functional and logical architectures and the requirements, I asked the agent to develop 3 physical variants that each notionally optimize a different aspect of the requirement space. Here\u2019s what it came up with:<\/span><\/div>
Alternative<\/span><\/div><\/td>
Built to maximize<\/span><\/div><\/td>
Design concept<\/span><\/div><\/td><\/tr>
HyperCook<\/span><\/div><\/td>
Throughput <\/span><\/div><\/td>
Four parallel continuous cook lines <\/span><\/div><\/td><\/tr>
LeanBroth<\/span><\/div><\/td>
Resource-budget margin<\/span><\/div><\/td>
Two batch kettles, one prep station, and fewer overall components<\/span><\/div><\/td><\/tr>
EverSimmer<\/span><\/div><\/td>
Mission assurance<\/span><\/div><\/td>
Three independent production cells, each a complete prep-cook-quality control-pack chain<\/span><\/div><\/td><\/tr><\/table>
I asked the agent to create a simple diagram of each variant so I can see what it is proposing. It did <\/span>that<\/span><\/a> very cutely using MATLAB figures. <\/span><\/div>
HyperCook<\/span> prioritizes throughput with four parallel continuous cook lines.<\/span><\/div>
<\/span>\"\"<\/img><\/a><\/div>
LeanBroth<\/span> prioritizes budget margin with two batch kettles and one prep station.<\/span><\/div>
\"\"<\/img><\/a><\/div>
EverSimmer<\/span> prioritizes robustness: three fully independent production cells, each a complete prep-cook-quality control-pack chain. You can still produce soup even if one or two entire cells fail.<\/span><\/div>
<\/span>\"\"<\/img><\/div>
These all looked like reasonable concepts, which was good enough for my purposes to call them validated. So, I had the agent implement them in System Composer architecture models, including data dictionaries, requirements traceability links, and allocations between the functional, logical, and physical models. <\/span><\/div>
One implementation decision I want to point out: these are three separate architecture models, not variant components in one model. The variants differ in topology, hierarchy depth, and component count, and each needs its own allocation set. I reused the interface dictionary and stereotype profile across the three architecture models. You can see all of those <\/span>here<\/span><\/a>. <\/span><\/div>

Architecture Views<\/span><\/h2>
As these architectures grew complex, <\/span>architecture views<\/span><\/a> became especially useful for understanding the design. <\/span><\/div>
Here\u2019s what the HyperCook physical architecture looks like at the top level: <\/span><\/div>
\"\"<\/img><\/div>
That\u2019s not totally unmanageable, but there are a lot of crossing connections owing to the fact that every component has a connection to the supervisory controller. Here\u2019s a custom view I made that filters that out: <\/span><\/div>
\"\"<\/img><\/div>
Now that I had 3 variants, it was time to analyze them.<\/span><\/div>

Analyzing Architectures<\/span><\/h2>
How do you analyze an architecture? <\/span>This page<\/span><\/a> in our documentation explains the basics of architecture analysis. As is described in that page, the agent generally followed this workflow:<\/span><\/div>