Troubleshooting

Installation

No. You will be prompted to replace the existing version when you import the new version.


After importing the plugin, you must restart your No Magic modeling tool to complete the installation. The Moxie menu will appear after your modeling tool restarts.


Select Moxie > About to verify your Moxie version.


These indicate that you need to open the Moxie Client Licensing Settings as an administrator (right-click it and select Run as administrator, entering your administrator credentials when prompted).


This indicates that Moxie cannot find your license. Double check all of the following:

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

    If you installed Moxie for all users, you must open the settings as an administrator (right-click it 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 license installed that includes Moxie. If you do not have a Moxie license installed, select Add a License File to add one.

Running a simulation

If your simulation fails, you should begin your investigation by looking at the simulation console and log file. In addition, run the model validation report to check the validity of the syntax in your state machines.

Commonly encountered error messages and suggested solutions:

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 occurs 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. 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.

"Simulation terminated unexpectedly due to an exception." This is typically caused by one of the following errors:

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.

Moxie does not require a license for the STK Components development kit, but your delegate module(s) may. To request a license for the Components development kit that you can deploy with you delegates, contact support@agi.com.

If you already have a license for STK Components, you can compile it into your delegate module yourself by placing it in the resources folder before building the project. Alternatively, you can create a zip file containing the license file, AGI.Foundation.lic, rename it to *.jar instead of *.zip, and place it alongside the other *.jar files in your delegate module directory after building and installing your delegates. Either method will include it as part of your delegate module.

This indicates that Moxie cannot find your license. Double check your licensing settings.


This can happen if you click the wrong Run button.

When executing a Moxie simulation, make sure to use the Run () button on the main Simulation Execution toolbar. If you do not see the toolbar, select View > Main Toolbars > Simulation Execution. You can also run a simulation from a simulation configuration diagram by right-clicking in the diagram and selecting Simulation > Run (or by pressing CtrlAltX). Do not use the Run () button on the diagramming toolbar, as this will not trigger Moxie to execute.

Also, make sure that your Engines Priority list has the Moxie Engine at the top, otherwise the Moxie Engine will not be used.


Ensure you have the Moxie plugin installed before you run the simulation. Please see the Installation Guide for more information. Also, remember to restart your No Magic modeling tool after installing the plugin in the Plugin/Resource Manager.

Ensure Moxie Engine is at the top of the Engines Priority list in the simulation configuration before running a simulation.


Most likely, this is because Cameo Simulation Toolkit is not installed or isn't licensed correctly. Please see the Installation Guide for more information regarding Moxie prerequisites.


This is often seen 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.


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.

Using STK components

It is possible that you are converting from MoxieTime to JulianDate incorrectly. JulianDate by default will expect data represented as International Atomic Time (TAI) rather than Universal Coordinated Time (UTC). Since MoxieTime.toJulianTime() may be represented in UTC if it was originally converted from an ISO8601 string, it is important to ensure the time standards are consistent when converting.

To convert correctly from MoxieTime to JulianDate: 

com.agi.moxie.api.time.JulianTime time = moxieTime.toJulianTime().toTimeStandard(com.agi.moxie.api.time.TimeStandard.getInternationalAtomicTime());
agi.foundation.time.JulianDate jd = new JulianDate(time.getDayCount(), time.getSecondsOfDay(), agi.foundation.time.TimeStandard.getInternationalAtomicTime());

To convert correctly from JulianDate to MoxieTime: 

agi.foundation.time.JulianDate jd = julianDate.toTimeStandard(agi.foundation.time.TimeStandard.getInternationalAtomicTime());
MoxieTime time = MoxieTime.fromJulianTimeTai(jd.getDay(), jd.getSecondsOfDay());

You could also use UTC so long as the standards are consistent across the data. However, if there are different leap seconds configured between Moxie and STK components, be aware that the times may represent different instants. Both STK components and Moxie include historical leap seconds by default, and both provide a mechanism for including new (future) leap seconds. For more details, see the LeapSecondsFacet in STK components and the LeapSecondsProvider in Moxie.