← Blog

Model-based engineering for phased arrays: from a radar project to open-source tools

2026-07-09

For about a decade the same question has followed me around: how do you design a complex radar or antenna system when the answer depends on the radio physics, the hardware limits, the cost, and the mission all at once? No single calculation settles it. The path I found runs through model-based engineering and multidisciplinary design optimization (MDAO), and it started with a graduate radar assignment. Today it lives in a handful of open-source phased-array tools I maintain on my own time. This post is that throughline.

It started with radar

In graduate school at Virginia Tech I took the radar sequence and did two projects that stuck with me. One was a radar-systems design study; the other analyzed clutter-suppression methods for a ground-based L-band ARSR-3 air traffic control radar. Both reports are in my electromagnetics work samples.

The lesson from both was the same. A radar’s performance is a chain of coupled trades. The waveform sets the range and Doppler resolution, the antenna sets the gain and beamwidth, the clutter environment sets what you have to suppress, and the detector sets the probability of detection you can claim. Tug on one and the others move. You cannot optimize the antenna in isolation and expect the system to come out right. That is the moment I started wanting a way to hold the whole system in one model.

From single models to system trades

That way of working has a name. Model-based engineering (MBE), and its systems-engineering form MBSE, means connecting the discipline models of a system so that design decisions and requirement checks run against a shared, executable model rather than documents shuttled between teams. Multidisciplinary design analysis and optimization (MDAO) is the layer on top: running trade studies and optimization across those coupled models at once, so you improve the whole system instead of one part.

For a phased array that means tying together the RF pattern, the transmit/receive hardware, the power and thermal budgets, the size and weight, the reliability, and the cost, and then asking a single question of the connected model: does this design meet its requirements, and what does moving one knob cost everywhere else?

Applying it at Northrop Grumman

I got to do exactly that professionally. At Northrop Grumman I worked on model-based engineering for phased-array radar systems, and the public record of it is a conference paper and a vendor case study.

The SPIE 2017 paper, which I led, describes an integrated mission-level radar model: a 2016-era multidisciplinary team connected RF, power, control, size, weight, thermal, and cost models for an active electronically scanned array (AESA) into one model using ModelCenter, then linked that model to the Air Force’s AFSIM mission framework so performance and cost could be traded end to end, from a component up to a mission. The published ModelCenter case study reports the practical effect: analysis of a single design solution ran “in minutes compared to hours previously,” and automated connections between models removed the transcription errors that come from moving numbers by hand. My own line in that case study still sums up why I like the work: MDAO is “calculating system performance, checking requirements, and performing design trade-offs in a very quantitative fashion.”

I presented more of the method at the ModelCenter Users’ Conference in 2018 and 2020, and some of the antenna work led to a patent. Everything here comes from those public sources; the research page collects them, and I keep no internal detail in this post.

Bringing it home as open-source tools

I do not work on phased arrays day to day anymore. The pattern stuck anyway, so I rebuilt the ideas as open-source Python tools I maintain on my own time, layered the way a real design flows.

phased-array-modeling computes the radiation pattern with the impairments that actually matter: mutual coupling, phase quantization, tapering, and element failures. phased-array-systems sits on top and runs the requirements-driven trade studies: link budgets, radar detection range, RF-cascade noise, reliability, and cost, swept as designs of experiments and reduced to Pareto fronts. It is the closest open-source echo of the ModelCenter work, and the one I would hand a systems engineer first. EdgeFEM is the full-wave finite-element solver underneath, for when a unit cell needs real electromagnetics rather than an analytic element pattern. And APAB wraps the whole chain behind an LLM agent that calls the tools over the Model Context Protocol.

I wrote up the array model and the trade studies in modeling phased arrays in Python, and the agent layer in the agentic workflow post and its 0.3.0 release.

There is a metasurface strand too. My PhD moved from arrays to programmable metasurfaces and reconfigurable intelligent surfaces (RIS), and the same modeling-tools instinct produced metasurface-py, a BSD-licensed package for designing, analyzing, and optimizing programmable metasurfaces for wireless communication and sensing, with docs and a Streamlit demo. It is the same physics-and-constraints pattern applied to a different surface. I explained one slice of that research, encoding bits in which beam a metasurface forms, in the antenna is the modulator; the research page has the dissertation.

Looking forward: agentic design workflows

MBE and MDAO connected the discipline models so a trade could run end to end. The next step is letting an agent drive that connected model. APAB is my experiment in that direction: an LLM agent that plans and runs the RF tool chain, but wrapped in the same engineering discipline as the MBSE work. Every session writes a run bundle, an OpenTelemetry trace, and a provenance manifest, and the tool choices are scored against golden tasks, so a design decision stays auditable after the fact.

For complex engineering systems the appeal is broader and faster exploration of the trade space, with a person reviewing a traceable record instead of hand-running each tool. The honest caveats still hold. The models and the constraints have to be right, or a fast agent just reaches a wrong answer sooner. The durable value is the engineering tools and the audit trail, and the agent is the replaceable shell on top. The part I find worth building is agent-orchestrated MDAO that stays fully traceable, which is why APAB 0.3.0 spends its effort on provenance and evals rather than on the agent itself.

The throughline

The same idea shows up in grad school, at work, and in the open-source tools: model the physics and the constraints together, and make the trades explicit and checkable. Radar and phased arrays are the instance I happened to learn it on. The pattern is the point.

Try it

Everything is on PyPI:

pip install phased-array-modeling phased-array-systems edgefem metasurface-py
pip install "apab[ollama]"

The phased-array pattern and metasurface tools each have a browser demo (patterns, metasurfaces), the systems library ships trade-study examples, and the research page has the SPIE paper, the case study, and the presentations. If you think a number or an assumption is off, the math is visible in every one of them, and I would like to know.

This post draws only on public sources: the SPIE paper, the published ModelCenter case study, and presentations I posted publicly. It contains no proprietary or internal information. The views are my own and do not represent any current or former employer.