All features supporting the SysML v2 BETA specification are currently ALPHA and subject to change. The final SysML 2.0.0 specification is expected to be officially adopted in the second half of 2025. While there have been many questions during the finalization, we believe this implementation provides enough value for early adopters to start preparing to create and execute models using the new specification. We will be expanding support for the specification through finalization, into SysML v2.1, and beyond. There are a small number of remaining issues related to execution scheduled for revision in SysMLv2.1. We will be expanding and clarifying support for SysML v2.x throughout the upcoming language revision process. Consult the What's New and Modeling with SysML v2 pages for more information about what is currently supported.
Developing Delegate Modules
For those familiar with the previous method of creating delegate modules for SysML v1, please note that we have significantly streamlined and simplified the process of creating such reusable modules for SysML v2. Previously, this process involved building full classes to represent SysML blocks. Whereas, now, delegate modules represent an opportunity to opt in to providing functionality for key elements during execution.
Behavior Execution Engine provides you with the ability to integrate APIs from external analysis tools into your simulation. These analysis tools, such as the Ansys Systems Tool Kit® (STK®) application, can handle the physics complexities implicitly, without needing to build complex numerical computation to clutter your system models. This method frees the system model to focus on a realistic representation of the physical system rather than focusing on artificial numerical details that may in fact be inaccurate representations. This also enables you to change the level of fidelity and precision of your analysis to suit your analysis needs without affecting the clarity or accuracy of your model.
A delegate module is a Java class that can use the CustomCodeRegistry to delegate the behavior of
elements from your model to your code. Delegated action or calculation code essentially replaces decomposing the behavior of
elements to instead execute your code. Whereas, delegating the values of attributes can provide a mechanism for code to produce
continuous time values for use elsewhere in your model, especially when using bindings.
This topic provides a comprehensive overview of the Behavior Execution Engine delegate module architecture. It covers the Java API and various samples we provide to make developing your delegate modules as painless as possible. It also makes special note of how to expose physics-based change triggers in ways that are not feasible or scalable when using other tools.
If you plan to use an Integrated Development Environment (IDE) such as Eclipse, IntelliJ IDEA, or VS Code, you should set it up before you get started writing delegates.
For discussion of specific delegate module development topics, refer to the following:
- Delegate Module - The infrastructure to store, build, and register delegate modules
- Delegate Module Insights - descriptions of the implementation and processing of delegate modules
Understanding of Java is required for this reference. The custom analysis tools you intend to integrate do not need to be written in Java, but you must be able to call or otherwise interact with them from Java.
Troubleshooting
Please refer to the Troubleshooting page if you have any issues running your simulation with your custom delegate modules.