How VOLTA enables simulation and Cameo requirements integration for early verification and validation: insights from ESTECO’s domain experts

In today’s highly complex engineering landscape, the ability to integrate simulation and requirements early in the design process has become a key capability for improving both verification and decision-making. Bridging the gap between system requirements and detailed simulation models ensures that potential issues are identified sooner, reducing costly redesigns and accelerating time-to-market.

At ESTECO, we understand the challenges that engineering teams face in managing increasingly complex systems. To address this, our domain experts Roel Van De Velde, Vice President of Aerospace and Defense, Daniel Schmidt, Senior Application Engineer, and Marco Turchetto, VOLTA Product Manager, bring their unique insights on how the VOLTA digital engineering platform supports seamless integration of physics-based simulations with Cameo SysML requirements. By using VOLTA and its newly-introduced MBSE plugin, engineering teams can efficiently validate system requirements against physics-based artifacts, fostering greater collaboration and traceability throughout the entire design process.

The need and motivation for MBSE plugin for VOLTA

What inspired the initial push for this plugin? Was there a specific customer moment that made the gap between Cameo and VOLTA impossible to ignore?

Van De Velde: For years, we’d heard informal requests to connect system architecture models in Cameo with simulation workflows managed in VOLTA. But what really shifted things was the push across aerospace and defense, especially from the United States Department of Defense (DoD), for full adoption of digital engineering. That raised the bar for traceability and systems validation, and it made the disconnect between SysML models and simulation tools impossible to overlook. Customers struggled to verify performance early in the lifecycle because their system models resided in one environment and their simulation data in another. We saw a clear opportunity to help bridge that gap and make physics-based verification more accessible to systems engineers, not just analysts. That’s when we committed to building a lightweight, focused integration that brought simulation results back into the model with full traceability.

What problems did your aerospace and defense customers struggle with that existing tools couldn’t solve?

Van De Velde: The biggest challenge we saw was fragmentation. Aerospace and defense teams were using advanced tools, but those tools weren’t speaking the same language. System architects built detailed models in Cameo, analysts ran simulations in their environments, and the verification process relied on email chains, spreadsheets, or tribal knowledge to connect the two. This made traceability difficult, especially when requirements changed or designs evolved. There was no clean way to confirm whether a simulation result validated a system-level requirement, or even which version of the model it corresponded to. Existing tools were powerful in their silos but didn’t offer a clear, traceable path from system models to performance data and back. What these teams needed wasn’t another heavyweight platform, they needed a focused solution that could link SysML and simulation artifacts without overhauling their toolchain. That’s what this plugin is designed to do.

Why was ESTECO the right company to address this challenge?

Van De Velde: While we’ve had casual Cameo integration requests for a number of years, the recent push by the US DoD to fully embrace digital engineering has accelerated the necessity to offer this capability to our customers. The major pain point that we wanted to address was to automate requirement verification by analysis using physics-based artifacts, essentially bringing the MBSE and CAE worlds together - which prior to this newly developed capability were disconnected disciplines, mostly operating in isolation. We first had to implement the right API endpoints in our VOLTA framework, as we made a conscious decision to offer this capability on a server-based architecture only. We strongly believe that only server-based tools can enable a true digital thread - desktop tools just have too many limitations (e.g. lack of failover). We also deliberately decided to codevelop this capability with an external partner, whose expertise in MBSE proved of tremendous value, both from a development as well as application perspective.

Industry impact

How does this plugin align with broader trends in the A&D sector, such as the push for ASOT or SysML v2 readiness?

Van De Velde: We’re seeing clear demand across the aerospace and defense sector to establish an Authoritative Source of Truth (ASOT) and move toward more model-centric, traceable engineering processes. This plugin supports this direction by providing teams with a structured way to connect system requirements with physics-based verification, and to maintain that connection as the design evolves. In terms of SysML v2, we’re closely monitoring its adoption, but most programs today are still building their workflows in SysML v1. That’s where this plugin is focused. We designed it to support real-world MBSE workflows that teams can implement today, without waiting on full v2 migration. At the end of the day, it’s not about chasing standards for their own sake; it’s about enabling decisions based on reliable, validated system data. That’s where we believe this plugin adds immediate value.

How important is traceability and compliance in your customers’ MBSE workflows, and how does this solution help?

Van De Velde: Traceability is foundational, especially in aerospace and defense, where teams need to justify design decisions, demonstrate verification, and maintain a record of what was validated, when, and how. That’s not just a regulatory concern—it’s an engineering one. Without traceability, it’s nearly impossible to work across disciplines or scale your MBSE efforts.
This plugin helps by connecting system requirements to simulation results in a way that’s structured, persistent, and version-aware. It doesn’t generate compliance reports or claim to meet specific standards, but it gives engineering teams the traceability backbone needed to support compliance workflows.

Vision and next steps

What does this plugin mean for the future of ESTECO's presence in the A&D market?

Van De Velde: It’s a major step forward. We’ve supported aerospace and defense customers for years, primarily on the simulation and optimization side. Still, this plugin brings us deeper into their MBSE workflows, which are becoming more central to how programs are structured and evaluated. By connecting system architecture to simulation in a traceable, tool-agnostic way, we’re helping A&D teams move faster, reduce risk, and build confidence in complex system designs. And we’re doing it in a way that respects their existing tools and processes, with no need for a rip-and-replace approach. Looking ahead, this plugin is more than a one-off integration. It’s a signal that ESTECO is committed to supporting digital engineering at scale, with flexible, API-driven tools that fit the way real teams work. We see this as the beginning of a broader evolution in how our platform serves the A&D market.

What are you most excited about as customers adopt the plugin?

Van De Velde: What excites me most is seeing systems engineers and analysts finally working from the same source of truth, without having to force-fit their tools to work with each other's tools. This plugin makes it easier to answer the question: “Has this requirement been verified with real data?” And once teams can answer that with confidence, everything else improves: design decisions, stakeholder trust, review cycles.
We’re already seeing customers build traceable, testable workflows that would’ve taken months, or been impossible, without this kind of integration. That kind of progress, grounded in real engineering, is what we’re here for. While this capability was initially shaped by the needs of the aerospace and defense sectors, it is also applicable across industries facing similar challenges, such as automotive, healthcare, and industrial automation. This flexibility is a key aspect of ESTECO’s independence. We are not tied to any specific software ecosystem, allowing us to remain flexible, tool-agnostic, and focused on what engineers need across various sectors.

The technology behind MBSE plugin for VOLTA

For someone less technical, how would you describe what this plugin does in plain terms?

Schmidt: It connects your system model in Cameo to the simulations you use to verify it, so you can track how a requirement was tested, what the result was, and when it happened. The plugin lets you define which simulation parameters and results are linked to specific elements in your model. After a simulation runs in VOLTA, you can bring the results back into Cameo and see whether your requirements were met, without copy-pasting values or manually updating diagrams. It’s not a black box. It just gives engineers a structured, repeatable way to trace simulation-based verification inside their modeling environment.

Can the plugin be used with internal block diagrams (IBD) where value flows pass through ports?

Schmidt: Not directly. The plugin works with value properties in the model, it doesn’t trace ports or flows on IBD diagrams. That said, if those value properties represent flow behavior, you can still link them to simulation parameters. In other words, the plugin doesn’t follow the value flow through the diagram, but it can reference the data that flow represents, as long as it’s modeled with a value property that has the right stereotype applied.

What were the biggest challenges in making Cameo and VOLTA “talk to each other”?

Schmidt: The hardest part was making the connection lightweight, flexible, and traceable, without forcing users to change how they model or simulate. Cameo and VOLTA weren’t built to exchange data directly, so we had to define a clear mapping between SysML value properties and the simulation parameters VOLTA manages. On the VOLTA side, we needed APIs that could handle those mappings, respect versioning, and preserve references over time. Another challenge was making sure the plugin fit into existing workflows. We didn’t want a tool that only worked in ideal conditions; we wanted something engineers could use without re-architecting their entire model or simulation setup.

How does this plugin handle verification and validation workflows in a way that supports traceability?

Schimidt: The plugin establishes persistent references between SysML value properties in Cameo and the simulation parameters and results managed in VOLTA. Once you define what to verify, a requirement, constraint, or metric, you can link it to a simulation input or output. When the simulation runs, the results are brought back into Cameo and attached to the exact model element they correspond to. That link stays intact, even as the simulation is updated or rerun. This creates a clear audit trail: what was verified, when, with what data. It’s not automated V&V, but it gives teams a structured way to trace simulation-based validation directly inside their modeling environment.

Engineering value

What’s unique about how this plugin moves data between tools, especially compared to other integrations you've seen?

Schmidt: In general, we’ve seen two dominant strategies for tool interoperability. One creates a general, flexible data bus where many tools subscribe to shared sources and dynamically push or pull data. The other creates a direct, purpose-built bridge between tools, focused on a specific need. This plugin follows that second path. It establishes a focused connection between Cameo and VOLTA, specifically designed to handle simulation test plans and import simulation results for verification of requirements. The key benefit? It minimizes complexity. Cameo users don’t need to learn a new tool or overhaul their workflow. They stay in their modeling environment and define what simulation data they want to retrieve.
The plugin handles the data transfer, yes, by copying the results, but does so in a way that maintains traceability. Each imported result remains linked to its corresponding model element, making requirement verification and audit trails easier to manage. This model-driven, streamlined approach is what sets it apart. It’s not trying to be everything to everyone. It’s designed to deliver value quickly and clearly for a real-world engineering challenge.

Can you walk us through what a “day in the life” might look like for an engineer using the plugin?

Schmidt: An engineer might start by reviewing system requirements in Cameo and identifying key parameters that need validation. Using the MBSE plugin for VOLTA, they select those value properties and associate them with parameters managed in VOLTA. Once that’s set up, they can initiate simulations from VOLTA based on the model configuration. When simulation runs are complete, the engineer can browse a catalog of available results and import specific values directly into Cameo. The results are presented as instances and linked to the corresponding model elements. This gives the engineer visual feedback, typically in an Instance Table, on whether design targets were met. If a requirement changes, they can quickly trace which simulations are affected, refine the inputs, and rerun the analysis. The goal isn’t to automate the whole process, but to make simulation-based verification repeatable, traceable, and model-driven, all within Cameo.

How is simulation data traceability handled in stochastic simulations where results vary between runs?

Schmidt: When simulations involve randomness, like Monte Carlo analyses or mission variability, you’re not validating a requirement with a single output, but results from a sampling of possibilities. This can be done two ways; either have VOLTA run a DOE over different random values, and import the whole distribution of results, or have the workflow manage the sampling and extraction of an aggregate result, such as a mean, range, or confidence bound. The plugin supports this by allowing you to choose which result you want to bring into Cameo. It doesn’t interpret the data; it just creates a persistent link between the requirement and the selected value. That way, even if results vary across runs, you can still trace the outcome used for validation and see where it came from.

Future enhancements

Are there future capabilities already on your mind?

Schmidt: We were given a focused goal for the first release: support SysML v1 models in Cameo and enable traceable connections to simulations managed in VOLTA. That’s what we delivered, and we’re happy with the stability and usability of the current version.
That said, we’ve discussed ideas for improving the user experience, things like simplifying the linking process or improving how results are visualized inside the model. But we want future updates to be shaped by actual user feedback, not assumptions. So the priority now is adoption: getting the plugin into real workflows and learning from how teams use it.

How does this plugin set the stage for broader interoperability across the MBSE toolchain?

Schmidt: This plugin is designed with a narrow scope: connecting SysML v1 models in Cameo to simulation results managed in VOLTA. It’s not intended to serve as a general interoperability framework, but it can play a role in helping teams establish traceability across tools they already use. For some organizations, it may act as a stepping stone: a lightweight way to start connecting requirements with verification data in a structured way. It’s especially useful in cases where the toolchain is limited or where IT constraints prevent adopting larger-scale digital thread solutions. For broader interoperability across the MBSE ecosystem, including PLM, ALM, and semantic integration, we often point customers to our technology partners who specialize in that kind of orchestration.

MBSE plugin for VOLTA: roadmap

What was your primary goal when scoping this plugin’s functionality?

Turchetto: We wanted to unify VOLTA’s simulation process automation capabilities with MBSE practices - specifically, by tightly coupling MDO workflows with SysML requirements managed in architectural modeling tools such as Cameo Systems Modeler. To illustrate this approach, consider a generic aircraft engineering design project. In such a scenario, you often need to evaluate complex trade-offs across multiple physical domains—such as mission performance, structural integrity, aerodynamics, and propulsion efficiency. Using VOLTA, you can orchestrate a chain of CAE solvers, each specialized for a particular domain, into an automated multi-physics simulation workflow which facilitates the execution of MDO analyses. Crucially, the design objectives and constraints for the aircraft—such as weight limits, fuel efficiency targets, structural safety margins, and mission range—are directly linked to the system requirements defined in the architectural modeling tool. This tight coupling ensures traceability: any changes in system requirements are reflected in the MDO setup. As a result, we also realize one of the key principles of MBSE: establishing a living digital thread. VOLTA’s open architecture and its simulation process and data management (SPDM) backbone ensures that system models, simulation workflows, and validation results remain continuously aligned and up-to-date, enabling faster, more confident decision-making.

How did you prioritize which features had to be in the first release?

Turchetto: The primary objective was to establish a robust connection between parametric diagrams in Cameo and simulation analyses in VOLTA. This integration is crucial for sustaining the Verification and Validation (V&V) scenario, enabling engineers to determine if a product's architectural configuration meets its specified requirements using the simulation without the need for physical prototypes. The process begins by identifying and linking the key entities within each system:

• In Cameo: The architectural model is defined by its requirements and its bounds/values.
• In VOLTA: Complex systems are represented by simulation models. The characteristics of a specific design are determined by its input parameter values, while its performance expectations are governed by outputs, objectives and constraints, which correspond to the architectural requirements.

To effectively simulate and verify these complex and often multidisciplinary product models, ESTECO's simulation process automation technology is used. This technology enables CAE Engineers and Method Developers to create and manage sophisticated simulation workflows. Each workflow can be paired with an execution Plan, which defines the execution strategy by specifying an input domain, constraints, and performance objectives. This workflow and its associated Plan (run configuration) become the definitive simulation model for verifying the architectural design. To establish the fundamental link between the architectural and simulation models, the following features were identified as the priority ones for the connector:

• Simulation Model Selection: the ability to select the appropriate simulation model from VOLTA and associate it with the corresponding architectural diagram in Cameo.
• Parameter Mapping: each bound/value from the Cameo architectural model must be linked to a corresponding parameter within the input domain of the VOLTA execution Plan.
• Requirement Mapping: the requirements specified in Cameo must be mapped to the constraints defined in the Plan associated with the VOLTA automation workflow.

These three features create a direct correspondence between the architectural model in Cameo and its simulation counterpart in VOLTA, forming the basis of the integrated V&V process. The last logical step in this integration is to re-import the simulation results from VOLTA back into Cameo. This would empower system engineers to directly view and verify which designs successfully satisfy the initial requirements, all within the Cameo environment.

What changes or enhancements were made to VOLTA to support this plugin?

Turchetto: No significant enhancements were necessary for the VOLTA platform to support this integration. The connector solution was developed entirely by leveraging the existing VOLTA Public APIs. These robust APIs have been publicly available since 2018 and have been consistently maintained and improved over the years in response to customer feedback. Consequently, no substantial modifications to VOLTA's core were needed, as its architecture was already inherently designed to manage Verification and Validation (V&V) scenarios.

How does VOLTA now better support systems engineers using Cameo?

Turchetto: Fundamentally, VOLTA now empowers a new key group: systems engineers. For the first time, those responsible for defining system architectures can directly leverage simulation to verify their designs.
This new connector completes the engineering loop, creating a seamless, end-to-end workflow. The process now flows from the initial architectural definition by the systems engineer, through simulation and analysis, and concludes with the final validation of the product's architecture, effectively closing the gap between design and verification.

How are you thinking about onboarding new users who may not be familiar with ESTECO tools?

Turchetto: Because the plugin is built on VOLTA’s server-based architecture, onboarding benefits from the same principles we’ve applied to the platform: role-based access, guided workflows, and structured documentation.
We expect some users, especially systems engineers, to be less familiar with simulation tools or VOLTA itself. That’s why the plugin is designed to let them operate entirely within Cameo, using pre-configured templates and mappings defined by simulation or method developers. This separation of roles simplifies adoption and ensures that each team can focus on their domain without needing to master the entire toolchain.

Practical advice and potential impact in your organization

What advice would you give to an organization looking to connect simulations to SysML and how to use this to build on their MBSE journey?

Van De Velde: Start small with a focused, high-value use case, something that helps your team answer a real engineering question faster or more confidently. Don’t try to “implement the digital thread” all at once. Instead, build trust in the process by making requirement validation more transparent and repeatable.

Schmidt: Keep your models clean and consistent, especially your use of value properties and stereotypes. The more structure you build in from the start, the easier it is to trace requirements to simulations later. Don’t over-model; model what you plan to verify.

Turchetto: Treat architecture and simulation as two parts of the same system definition. Connecting them early allows you to define not just what the system is, but how its performance will be evaluated. That’s what turns a static model into a validation-ready engineering tool. Our plugin formalizes that link, without forcing changes to how teams model or simulate.

If you could sum up the impact of this plugin in one sentence, what would it be?