Troubleshooting

Installation

This indicates that the NoMagic tool cannot resolve the mdzip referenced from this project (see the order resolution at the top of the model libraries user help page). The model libraries user help page also contains instructions on how you can manually point the tool to Moxie-Base.mdzip located in the modelDependencies folder of the BEE installation directory. Alternatively, you can follow these steps to add the model dependencies to the NoMagic modeling tool's modelLibraries directory.


This error may occur from BEE finding duplicate models in different locations. Take note of the model resolution order found at the top of the model libraries user help page and ensure that no models are being referenced in more than one location (this includes the core BEE libraries: Moxie-Core, Moxie-Base, and Moxie-STK). BEE, by default, will also look in the modelDependencies folder of the BEE installation directory which may result in the discrepancy.

Developing Delegates

If you are using the @AutoDelegateImplementation annotation, double-check the spelling and casing of your Java implementation to make sure it matches the block property or operation. The runtime code generation process may be creating one for you and calling that one instead.


Call event arguments are not available as named elements inside the state machine. To get around this, store the value of the parameter in a property in the implementation for your operation. After the operation executes but before the engine executes any other effects on the transition, that property will be available.


There are two common reasons for this: you might not be using a consistent time standard, or you might not be using consistent leap second values.

When converting from MoxieTime to your analysis tool's time type, you should specify the same time standard on both sides of the conversion. For example, to specify the time standard for Behavior Execution Engine in Universal Coordinated Time (UTC) or International Atomic Time (TAI): 

JulianTime julianTime = moxieTime.toJulianTime()
JulianTime utcTime = julianTime.toTimeStandard(TimeStandard.getCoordinatedUniversalTime());
JulianTime taiTime = julianTime.toTimeStandard(TimeStandard.getInternationalAtomicTime());

You should also make sure that both sides of the conversion use the same set of leap seconds. Behavior Execution Engine includes historical leap seconds by default, and enables you to add new (future) leap seconds through the LeapSecondsProvider.


First, check the Delegate Availability Report under Diagnostics to see whether it is showing up there. Make sure to check this with and without loading your specific SysML project. If it shows up in the environment with no project loaded, that indicates it was successfully deployed to the Delegate Home Directory. Otherwise, there may be an issue with the specific SysML project.

In your SysML project, check to see if the MoxieDelegateModulePaths stereotype was applied to your simulation. Note that as of 2024R2 the simulation is the element that implements the MoxieSimulation stereotype. The MoxieDelegateModulePaths stereotype is optional. If not applied to the simulation, the engine will load all available delegates it can find from the Delegate Home Directory. Otherwise, if the paths stereotype is applied, it will ONLY load the delegates specified by those paths. So if there are no paths, it won't load anything. Check to ensure the name of your delegate appears in the stereotype Tags and that the (relative) path is correct.

If after checking the above places the delegate module still isn't showing up in the Delegate Availability Report, check the Log to see if there is anything there indicating a failure in loading the delegate module. You may also try running the simulation again to see if that generates log messages indicating an error inside the delegate module.

Lastly, if there are errors, consider running the session with Debugging turned on and placing a break point inside your DelegateProvider class to see if it is being loaded at all.

See also the section on this topic in the Delegate Module Tutorial.

Interacting with the SysML Model

The concept of mounting SysML Models as packages is not supported in Behavior Execution Engine. As of version 2025R1, all imported model dependencies are now loaded and displayed separately from the main project model package.

Running Simulations

If you see this error in the simulation log file for a type using @AutoDelegateImplementation, ensure that the indicated property or method has the correct type. Return types can be covariant but parameter types cannot. Ensure that all types occurring in method signatures correspond to their respective types with the @DelegateFor annotation, and that the qualified name is correct. For instance, if you have both an interface and a concrete implementation for a type and the interface has the @DelegateFor annotation, make sure to use the interface in any other Java signatures that reference that SysML model type.

This can occur in cases where there is a conflict between different versions of the same JAR file loaded by different delegate modules.

This can occur in cases where there is more than one instance of the @DelegateFor annotation for the same qualified name.

Whenever you see this error in the simulation log file, it usually indicates the block property or operation signatures do not correspond to the Java delegate signatures. First, run the model validation report to ensure that the state machines do not have any syntax errors. Misspelled property or operation names are the most common causes, along with missing implementations in the Java delegate code.

This exception will occur if the delegate module was not loaded correctly. If you receive this error, ensure the canonical name of your delegate provider is specified in path\to\your\delegate\module\resources\META-INF\services\com.agi.moxie.spi.DelegateProvider.

This exception can occur when the Java implementation does not require a particular value and a value was not provided for the slot in the Instance Specification, but during execution another instance attempts to access that property. In other words, the setup works fine but then there is no value available at runtime when delegates go to use the value of a property without checking for null. Make sure that values are specified for required slots or set the values manually inside the Java implementation.

The exception in the simulation log file looks like this:

Instance Specification 'Instance::Specification' (ID): SysML type 'Project::SpecializedDomain::Operation' had no default delegate implementation. Either apply the MoxieJavaDelegate stereotype for The_Operation or ensure that a registered Java class has the @DefaultDelegate annotation. (see Instance Specification 'Instance::Specification' (ID))

Ensure that any Instance Specification in your model that has corresponding delegates, has at least one of those delegates tagged with the @DefaultDelegate annotation or that the Instance Specification applies the MoxieJavaDelegate stereotype to specify which delegate to use.

This exception is indicative of a circular dependency between Java delegates. For example, in your block definition diagram, you may have two blocks that have a two-way relationship with each other, where each is a reference property on the opposing block. This is a circular dependency.

If you use the Java delegate code generator to auto-generate your delegate classes for these blocks, it will automatically include code to initialize each block's corresponding property in the constructor of the opposing delegate class. The solution is to remove one or the other from the constructor, and initialize it using the wireup process instead.


Run the Delegate Availability Report and make sure that all the method signatures - including their required parameter types - are being loaded. If any are missing or incorrect, make sure that their interfaces or classes are registered with your DelegateProvider.


This occurs when a transition that has been deleted from your state machine diagram still exists in the underlying data structure. As such, it is being traversed in the execution of your state machine even though you cannot see it. To reveal the transition in the diagram, right-click the state machine canvas and select Display > Display Inner Elements. Once you have located the problematic transition, you can permanently delete it by selecting it and pressing Delete.

Running simulations from the Ansys ModelCenter® application

This occurs when a required model dependency is missing.

Shortly before the final error in the log, you should see another error that states: "Cannot load the following resources:", followed by a list of the required files. Find these files, and move or copy them into the modelDependencies directory in the Behavior Execution Engine installation or alongside your MDZIP project file. If you created your project on a different machine than you are trying to run on, you may need to copy the files from that machine. If the files are standard libraries from a third party, try looking for them inside your modeling tool installation.

After adding the required files, right-click the Behavior Execution Engine component in the ModelCenter workflow or Component Tree and select Reconnect before re-running.