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.

Delegate Module Insights

This topic provides insights into the implementation and processing of delegate modules in Behavior Execution Engine. It addresses the following specific areas:

Delegate lifecycle

Before the start of a simulation, the application will collect all delegate modules that are in the sharedDelegateModulesDirectory and any in the optionally specified additionalDelegateModuleSearchDirectories. After it has collected all the delegate modules, the application will load all the specified delegateModules along with any transitive dependencies that those delegate modules have specified. During the loading step, the initialize(SimulationContext context) method is called.

When starting a simulation, Behavior Execution Engine uses the target element (e.g. a SysML use case) to start creating instances of all the SysML elements connected to the target element. If any of those elements have custom implementations registered for them, their behaviors will change to use the delegated implementation. More details can be found in the later sections.

After the simulation has finished, the application will start the process of unloading all the loaded delegateModules in reverse load order. During the unloading step, the application will call the deinitialize(SimulationContext context) method to provide a chance to clean up user-specific tools.

In summary, the delegate modules life cycle is as follows:

  1. Initialization of delegate modules
  2. Registration of all custom code
  3. Execution of simulation
  4. Deinitialization of delegate modules

Delegating for actions

Your delegate module can have custom code registered to execute during the execution of an action (or calculation) during simulation. You can achieve this by providing an implementation of the ExecutableActionCode interface along with an identifier for the target action. For calculations, this would instead be an implementation of the InvocableCalculation interface. In these functional interfaces, you are given a context API with access to system services for the live instance of the target element during simulation.

The ExecutableActionCode interface requires you to return a DelegationResult to indicate possible future execution of this delegate. If the NoAdditionalEvents instance is returned, this will alert Behavior Execution Engine to end the delegated action. However, if you wanted to specify a future event to extend execution of the delegated action, you can use a FutureActionEventResponse. This is the delegate module equivalent of modeling an action that owns an accept action with an absolute time trigger with a succession to another owned action.

For the InvocableCalculation interface, there is no return value in Java. This is because calculations have a requirement that they must not take any time. Therefore, the functional interface has a void return type and the SysML return value is provided by assigning to the result of the calculation.

Delegating for scalar values

Your delegate module can delegate for the implementation of an attribute typed by a ScalarValue during simulation. This can be achieved by providing an implementation of the ScalarValueFeatureAccessor interface along with an identifier for the target attribute. The accessor will need to provide a way for Behavior Execution Engine to retrieve and modify the value of the attribute relative to the current simulation time. If you want to do more advanced simulation, e.g. use the attribute in a change trigger, you will then need to specify that the accessor can create a ScalarValueFeatureEvaluator. This would mean accepting a TimeInterval and performing calculations to provide the intervals within which the value satisfies the indicated comparison to the provided threshold.

See the tutorial tortoise vs hare part 2 for an example of a model using this custom threshold analysis.

Registering instance data

If you would like to attach a Java object to each instance of a SysML element, you can do that with your delegate module. This can be achieved by providing an implementation of the InstanceDataConstructor interface along with the Java class of the constructed data and the identifier for the element type (usage or definition) to represent. This means that for every instance of the element, Behavior Execution Engine will create a new instance of the provided data, which you can retrieve within other custom code using the provided context services for that instance.

Listening to time advanced in the simulation

For more advanced use cases, you may want to perform custom logic when Behavior Execution Engine advances time in the simulation. This can be achieved by providing an implementation of the SimulationTimeAdvancedListener interface. Every time the simulation time advances between discrete events during execution, the listener's callback will be executed. Notably, the engine will execute the callback after advancing the simulated universal clock but before it processes the next discrete events at that new time.

Thread safety between BEE and the delegate module infrastructure

The execution of elements is a synchronous process that simulates potentially asynchronous behaviors for the systems under design in SysML v2. While the systems may be operating in parallel inside the digital simulation, the execution software ensures that all system responses happen in an ordered and precise fashion. Due to this, all execution of delegate module code occurs sequentially, even though successive calls may all occur at the same simulation time instant. Any threaded or concurrent processes created within delegates must respond in sequence to the execution of delegated implementations simulating any retrieval, assignment, and analysis that occurs during execution. They also must honor the current simulation time provided by the TimeService. This is contrary to many real-time co-simulation frameworks and is intended to simulate complex mission systems accurately and precisely. Such systems may often run much faster than real time but in some cases may run slower than real time to support high-fidelity physics calculations. Behavior Execution Engine ensures that the combination of these different approaches work together without violating the semantics of the SysML standard.