A delivery robot crossing a parking lot looks simple until you try to write its requirements. It has to perceive a scene, decide whether the moving thing on its left is a shopping cart or a child, and act, all in a few hundred milliseconds, with no operator in the loop. The behavior isn't fixed at design time. It emerges from sensors, an AI policy, and the environment interacting. That's the problem autonomy hands to systems engineers, and it's why so many teams are reaching for MBSE to model machines whose behavior they can't fully specify up front.
Traditional systems engineering assumes you can decompose a system into functions and allocate each one to a component. Autonomy breaks that assumption. The "decide" function isn't a flowchart, it's a learned model, and its output depends on data the engineers never saw. MBSE doesn't make that uncertainty disappear, but it gives you a structured place to reason about it.
Why autonomy resists classic decomposition
In a conventional architecture you can trace a requirement to a function to a part and check the box. With an autonomous system, the same requirement ("avoid pedestrians") maps to a perception stack, a decision policy, an actuation chain, and a set of operating conditions that together produce behavior. None of those alone satisfies the requirement. The behavior is a property of the whole loop running in a context.
This is where modeling earns its keep. A model can represent the perception-decision-action loop explicitly, capture the conditions under which the system is allowed to operate (the operational design domain), and link each safety claim to the parts of the loop that support it. You're not modeling a fixed function anymore. You're modeling a capability and the envelope it's trusted to work inside.
Levels of autonomy change the architecture, not just the software
One of the more useful ideas coming out of recent research is that the level of autonomy is an architectural driver, not a software detail. Work presented through INCOSE on Systems of Autonomous Systems (SoAS), building on the Object-Oriented Systems Engineering Method and tailoring the Unified Architecture Framework, makes the point that each Level of Autonomy carries different organizational and technical implications for how you architect the system of systems.
A teleoperated robot, a supervised-autonomy robot, and a fully autonomous one are not the same system with different code. They have different human roles, different failure modes, different communication needs, and different verification burdens. Modeling the level of autonomy as a first-class architectural choice forces those differences into the open early, instead of discovering them during integration.
Systems of systems make it harder, and more necessary
A single robot is a system. A fleet coordinating in a warehouse, or autonomous platforms folded into a larger defense or logistics architecture, is a system of systems, and increasingly a system of autonomous systems. Stakeholders want the new capability that AI-empowered platforms provide, but those platforms have to be integrated into architectures that were never designed for elements that decide for themselves.
That integration is where models pay off. A SoS architecture has to express which decisions are delegated to which platform, how authority shifts when communication drops, and how emergent fleet behavior stays inside acceptable bounds. Architecture frameworks like UAF give you the views to capture those relationships across operational, resource, and security perspectives. Trying to hold that in documents and slides, across multiple autonomous elements, is how programs lose the thread.
Tooling: SysML, domain profiles, and the simulation gap
The tool landscape reflects the pull toward executable, simulation-connected models. General-purpose SysML environments such as Dassault's Cameo Systems Modeler, Eclipse Capella, and Dalus are used to author system architectures and, with SysML v2, to expose models through APIs that downstream tools can query. Alongside them, researchers have built domain-specific profiles like ROS2ML, a SysML profile aimed at autonomous mobile robot development, to narrow the distance between the architecture model and the ROS-based software that actually runs.
The harder gap is simulation. Autonomous behavior only really shows itself when you run it, so teams connect their models to digital twins and let robots experience years of varied situations overnight before any hardware moves. The catch is synchronization. Keeping a virtual model aligned with an evolving physical robot means matching not just geometry but timing, and ROS simulations often need a real-time Linux kernel to behave comparably to the physical system. Large autonomous systems also strain traditional MBSE tools, which weren't built for the computational load of real-time, high-fidelity simulation.
What MBSE won't solve for autonomy
A model of an autonomous system is still a model. It will not tell you whether a neural network generalizes to a scene outside its training data. It can document the operational design domain and trace which test cases cover it, but it can't certify that the AI policy behaves at the edges, and it can't substitute for the field data and simulation runs that expose unknown failure modes.
There are real trade-offs. Building and maintaining executable, simulation-linked models costs more effort than a static architecture, and that cost is wasted if the model drifts out of sync with the software and the twin. Domain profiles like ROS2ML add fidelity but also lock you into toolchains and require expertise that's scarce. And no framework removes the fundamental tension a 2026 IEEE Aerospace MBSE panel put plainly under the banner of "keeping the SE in MBSE": the modeling can become an end in itself, absorbing effort that should go into understanding stakeholder needs and the system's real behavior.
Bottom line
Autonomy is where the limits of document-based systems engineering get expensive fast, because the behavior you care about emerges from a loop you can't fully specify. MBSE helps by making the level of autonomy an architectural decision, by giving systems of autonomous systems a place to express delegated authority and emergent behavior, and by connecting architecture to the simulations where autonomous behavior actually reveals itself. It won't validate the AI for you, and it won't pay for itself if the model and the running system drift apart. Treat the model as the structure you reason and test against, not as proof the robot will do the right thing, and it earns its place in the toolchain.