SysML v2 and AI Reshape Systems Engineering: A Practical Look at the Shift

The Problem: Documents Can't Scale

Systems engineering has a productivity problem. Teams working on complex aerospace, defense, and automotive programs still rely heavily on static documents and descriptive models that don't connect to the data streams they generate. When a requirement changes, engineers spend weeks tracing impacts through disconnected spreadsheets, design files, and test reports. The feedback loop between simulation results, test outcomes, and architectural decisions remains broken.

Becky Petteys, systems engineering segment manager at MathWorks, puts it plainly: "Traditional descriptive models and static documents are no longer sufficient to manage the scale, interconnectivity, and pace of modern systems."

Her assessment draws from 19 years at MathWorks, including time as application engineer and team lead working directly with aerospace and defense companies on certification workflows. She now leads technical engagement for System Composer, MathWorks's MBSE platform.

The Solution Stack: Data-Centric Repositories, AI Assistants, Executable Models

The fix isn't a single tool. Petteys describes a three-part shift underway in the industry.

SysML v2 moves models out of files and into shared repositories. Instead of version-controlled model files scattered across team drives, version 2 uses data-centric repositories accessible across tools and domains. This removes long-standing interoperability barriers between system architecture, requirements, analysis results, and verification artifacts.

AI assists without replacing engineers. Petteys identifies specific use cases: model discovery across large repositories, reduced-order modeling for faster simulation, impact analysis when requirements change, and automation of repetitive work like documentation updates. The technology serves as a force multiplier on engineer time, not a replacement for engineering judgment.

Connected data enables system-level questions. When simulation results, test outcomes, requirements, and architectural elements exist as linked artifacts rather than isolated files, engineers can query system behavior directly. Petteys notes that knowledge-graph-like structures emerge naturally from these digital threads, making system-level insight accessible without manual data wrangling.

What This Means for Program Execution

The practical impact centers on iteration speed and decision quality.

Executable, analyzable models let teams simulate behavior before building hardware. When data connects across the lifecycle, trade studies move from intuition-driven discussions to data-grounded assessments. Change impact analysis that previously took weeks can run in hours.

Teams also gain alignment without additional meetings. When architecture decisions link directly to requirements and verification artifacts, cross-functional reviewers can trace logic without scheduling coordination cycles.

"This shifts systems engineering from experience-based practice toward science-grounded discipline," Petteys says. "Executable models let you ask 'what if' questions with actual data behind them."

The Bottom Line

The industry is mid-transition. Not every team has migrated from file-based workflows, and repository tooling still varies across vendors. But the direction is clear: systems engineering tools that treat models as data sources, not artifacts, will dominate the next decade. Teams still relying on static documents for complex programs should treat this as an urgency signal, not a trend to watch.

##

M4S TAKE

My take: certifications like this matter because they give buyers a defensible reason to shortlist a supplier. In a market where everyone claims quality, third-party validation is the difference between being considered and being ignored.

Simon McLoughlin