Troubleshooting

Installation

These indicate that you need to open the Behavior Execution Engine Client Licensing Settings as an administrator. When opening the settings, right-click the shortcut or executable and select Run as administrator, entering your administrator credentials when prompted.


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

See the Developer Environment topic for recommendations on how to configure your IDE.


This is likely an issue with locating the installed "api" folder or "delegates" folder containing the published libraries for delegate development. Check your "settings.gradle" file to ensure the paths to the "install" folder are correct. Make sure to use '/' as the directory delimiter. Gradle may be interpreting '\' as an escape character, causing the directory path to resolve incorrectly.

If checking the "settings.gradle" file doesn't help or you are using another build tool other than gradle, you may need to revisit your dependencies and ensure that the contents of the %BEE_Install_Dir%/api directory are included in the build.


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.

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.

This indicates that Behavior Execution Engine cannot find your license. Double-check your licensing settings.


This indicates that Behavior Execution Engine cannot find your license. Check the following:

  • Open the Behavior Execution Engine Client Licensing Settings and make sure that the Port and Server 1 are set correctly and saved.

    If you installed Behavior Execution Engine for all users, you must open the settings as an administrator. When opening the settings, right-click the shortcut or executable and select Run as administrator, entering your administrator credentials when prompted.

  • On the license server, open the Ansys License Management Center and make sure that the license manager is running.
  • Still in the license manager, under License File Options, select View FlexNet License, and verify that you have a Behavior Execution Engine license installed. Behavior Execution Engine licenses use the key moxie_sysml. If you do not have a Behavior Execution Engine license installed, select Add a License File to add one.

This means that STK (not Behavior Execution Engine) cannot find its license. Manually try to open STK, and you should get a dialog box that states: "A current STK license could not be found." Click OK to open STK's client licensing settings, and refer to STK's licensing documentation to set up your STK license.

If you do not get a dialog box with an error message, and STK starts normally, then this error is most likely a version compatibility issue. Ensure you have installed the same release of both STK and Behavior Execution Engine.


This occurs when you do not have a compatible version of STK Engine installed. Ensure you have installed STK Engine version 12.9 or later. See the Prerequisites topic for details on supported versions.


This could be a timing issue driven by the difference in precision between the two tools with respect to time and date. The default time precision for STK is at the millisecond level, but you can increase this precision. First, you must have STK installed and have saved at least one scenario. Then find the file called _Default.ap, which should be in C:\Users\<username>\Documents\STK 12\Config\Defaults\_Default.ap. Open the file in a text editor and go to the Precision section. Change the Date and AnimationTime values to 6 for nanosecond precision.


If your simulation fails, you should begin your investigation by looking at the simulation log file.


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 ModelCenter

This can occur when there are different versions of Behavior Execution Engine and ModelCenter installed on the machine. Check to ensure that the same Ansys product version was installed for both. This can sometimes be an issue if installing a different version of STK Enterprise compared to installing ModelCenter, or vice versa.


This can occur when Behavior Execution Engine is installed in Program Files.

Try copying the contents of the installation directory to another directory that you can access. Then, double-click the Behavior Execution Engine component in the ModelCenter workflow or Component Tree, select Options, and set BEE Install to the directory you copied everything into.


When running from ModelCenter, Behavior Execution Engine saves all its logs to the ModelCenter logs folder.


When ModelCenter interacts with the Behavior Execution Engine application, it starts a separate process to interrogate and execute the SysML project. If you manually close the console window for this process, or it otherwise dies without ModelCenter closing it, ModelCenter will still think the process is available.

Right-click the Behavior Execution Engine component in the ModelCenter workflow or Component Tree and select Reconnect. If you still see the error, you may need to restart ModelCenter.


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.


Ensure that you have the JAVA runtime installed and registered with your windows environment directories as the JAVA_HOME path specifying the path to the folder containing java.exe.