What's New

Behavior Execution Engine 2024 R2

New features and improvements:

• The SysML Client now has a model view that allows you to see and interact with state machines from an MDZIP SysML project. This includes simple debugging support during model execution. Specifically, this includes the ability to distinguish between different instances during execution even if they share the same behavior diagram. For STK application users, this helps distinguish which objects are participating in which state diagrams.
• The SysML Client's settings panel now provides a button to deploy the STK UI Plugin automatically. While this is a part of installing BEE, the plugin may not have been installed if the STK application was not available prior to installing BEE. This provides you the ability to ensure that the plugin is deployed correctly.
• Prior to starting a Behavior Execution Engine connection, the SysML Client UI now contains some simple diagnostic tools to help diagnose common reasons why the Behavior Execution Engine cannot run correctly.

Breaking changes

• Simulations now require the Moxie-Base::Configuration::MoxieSimulation stereotype applied to designate an instance as something Behavior Execution Engine can simulate. This means that any previous instances of Moxie-Base::Simulation::SimulationSpecification that do not have that stereotype applied will no longer show up as available simulations. To fix this, simply apply the MoxieSimulation stereotype to the existing SimulationSpecification instances. See more information in the corrected technical issues below.
• The BEE application data folder has been moved from %UserProfile%\AppData\Ansys\BEE to %LocalAppData%\Ansys\BEE. For users who have made changes to your application settings, you may have to reapply your settings.

Corrected technical issues:

• The previous version required use of the Cameo Simulation Toolkit "Sim Config" to identify what simulations are available in a SysML project. That dependency on the Cameo Simulation Toolkit stereotype was an oversight and has been removed. Now, simulations are identified based on elements that have the "Moxie-Base::Configuration::MoxieSimulation" stereotype applied, and users no longer need Cameo Simulation Toolkit as a dependency for their SysML projects.
• In previous versions, the "Simulation Specification" element type was used in template projects to allow users to specify which root elements to include in a simulation. However, this required specifying those root elements as specializations of "Moxie-Base::Structure::Thing". Those simulations will still work, but now any element with the "Moxie-Base::Configuration::MoxieSimulation" stereotype will now indicate a valid simulation, regardless of what types that instance specializes. This will help cases where users are extending model library types that do not extend the base "Thing" type from the Moxie-Base library.
• Added instructions to the Installation Guide that helps provide the Behavior Execution Engine modelDependencies folder as an alternate search path for SysML project dependencies.
• Clarified the behavior of the MoxieDelegateModulePaths stereotype as part of the Delegate Module Tutorials. The tutorials have been updated appropriately. For more information, see the Troubleshooting Guide for details on what to do when encountering issues loading delegates.
• Fixed an issue that caused simulations with an STK connection to fail with the presence of the Satellite Collection STK object.

Known issues:

• If there is a different version of the Ansys ModelCenter^® application or the STK application installed on the system, this may cause licensing errors due to a change in how the Ansys Client Licensing works. Using the current version of Behavior Execution Engine with older versions of the ModelCenter application prior to 2024R2 or the STK application prior to version 12.9 will not work. If you encounter issues with differing versions, please contact us so we can support you.

Behavior Execution Engine 2024 R1

Announcements:

• The installation of Behavior Execution Engine now includes a "SysML Client" user interface that provides a convenient way to interact with your SysML modeling project and also run simulations using the Delegate Modules that connect to your analysis and simulation tools. This comes in two form factors:
  1. For Systems Tool Kit (STK) application users, there is now a UI Plugin that provides the SysML Client inside the STK environment. See the setup guide for more details on configuring that plugin, which is installed automatically if you already have STK installed when installing Behavior Execution Engine.
  2. For other users, or users who prefer interacting with SysML outside the STK application, you will find the SysML Client Application in: %BEE_Install%/application/SysML_Client/SysML_Client_Application.exe
  For more information about using the SysML Client to run simulations, see Running Simulations. The new SysML Client also reintroduces new and improved Diagnostic Tools and Code Generation capabilities that were removed in 2023R2.1.

Behavior Execution Engine 2023 R2.1

Announcements:

• We have removed the MagicDraw and Cameo plugins as part of Behavior Execution Engine to pursue a more product independent and interoperable execution capability. For a statement on this major change, see the Overview remarks.
• The AnalysisWorkbench features in the STK Delegates have been deprecated in favor of recommending direct use of the STK Object Model for writing delegates against the STK application. The com.agi.moxie.stk.utilities package, specifically, contains several methods and classes relating to the STK Analysis Workbench capability features that have been annotated with @deprecated tags and may be removed in a future version.

Corrected technical issues:

• Fixed an issue that caused a simulation to fail without a useful error message due to a bad enum value. In cases where a value properties typed by a SysML enumeration had no value specified, attempts to dereference that value were throwing an unexpected null reference exception. Instead, it will now handle cases where not having a value will result in equality returning false or else produce a recognizable error pointing to the cause of the runtime problem in the expressions.

Behavior Execution Engine 2023 R2

Announcements:

• Behavior Execution Engine supports the 2022x Refresh1 version of No Magic modeling tools. See the Prerequisites topic for details on supported versions.

New features and improvements:

• Behavior Execution Engine simulations in ModelCenter application workflows now run without loading a SysML modeling tool. This saves time on each Behavior Execution Engine session, and it enables you to run simulations in parallel without needing multiple modeling tool licenses.
• Behavior Execution Engine now supports integrating with STK Engine (version 12.7 or later). See the STK Desktop versus STK Engine topic for more information on the differences between working with the STK desktop application and working with STK Engine.
• Behavior Execution Engine now supports $TIME operators in opaque expressions to make creating time events easier by enabling you to specify times in the events themselves.

Breaking changes:

• Directly using StkApplication to connect to the STK application has been deprecated. You should use either StkDesktopApplication or StkEngineApplication instead. See the STK Controller Dependencies topic for more details on using these classes.

Corrected technical issues:

• An issue with the error logging was obscuring when the Autostart Active Objects property of simulation configurations was incorrectly set to true. The log now correctly states that Behavior Execution Engine requires Autostart Active Objects to be set to false.
• The Moxie-Core model library was incorrectly including some transitive dependencies on the SysML v1.4 standard library. This should not affect most users, but the issue has been corrected so the model libraries included now only depend on the SysML v1.6 standard library.

Known issues:

• When running simulations from the ModelCenter application, only the MDZIP file format is supported. Trying to run an MDXML file will fail to load the simulation.
• When running simulations from the ModelCenter application, duplicate model dependencies may cause unexpected errors when loading your project. To make sure you do not have any duplicates, you may want to keep all of a project's dependencies in a single location, such as the modelDependencies directory in the Behavior Execution Engine installation.

Behavior Execution Engine 2023 R1

Announcements:

• Behavior Execution Engine supports the 2022x version of No Magic modeling tools. See the Prerequisites topic for details on supported versions.
• The IDE setup recommendations now include a section for VS Code in addition to the sections for Eclipse and IntelliJ IDEA.

New features and improvements:

• STK Enterprise's installer for Behavior Execution Engine now includes the STK delegates and STK model library so that you no longer have to install them separately.

  After running any installer for Behavior Execution Engine, you still need to import the plugins into your No Magic modeling tool.

Breaking changes:

• The SimulationProject getMagicDrawProjectName() method has been renamed to getProjectName(). This method is only used in custom AnalysisToolControllers, so this change is unlikely to affect your custom delegate development.
• Behavior Execution Engine no longer supports MagicDraw-specific primitive types:
  • UML Standard Profile::MagicDraw Profile::datatypes::double
  • UML Standard Profile::MagicDraw Profile::datatypes::boolean
  • UML Standard Profile::MagicDraw Profile::datatypes::int
  Instead, use the standard SysML types, respectively:
  • SysML::Libraries::PrimitiveValueTypes::Real
  • SysML::Libraries::PrimitiveValueTypes::Boolean
  • SysML::Libraries::PrimitiveValueTypes::Integer

Corrected technical issues:

• An issue with the Behavior Execution Engine plugin to No Magic modeling tools was causing errors when running Cameo Simulation Toolkit (CST), even when the Moxie Engine was not included in the Engines Priority of the simulation configuration. You can now run CST simulations that do not use Behavior Execution Engine while still having the Behavior Execution Engine plugin installed.
• An issue with the model validation report was incorrectly flagging integers as unable to be used as arguments to real/double operation parameters. The validator now correctly accepts either an integer or a real/double when an operation expects a real/double value.
• An issue with the delegate code generator was causing it not to include the @DelegateFor annotation for enumerations. Generated enumerations are now correctly tagged with @DelegateFor.
• An issue with the delegate code generator was causing java package mismatches when given package names with uppercase characters. Generated java packages are now converted to all lowercase, consistent with standard Java naming conventions.
• An issue with the element locator was preventing it from accepting the Element Server ID format used by Teamwork Cloud projects. It now correctly searches for elements in either local or Teamwork Cloud projects.

Behavior Execution Engine 2022 R2

Announcements:

• Behavior Execution Engine's STK delegates and STK model library are now only available if you acquired Behavior Execution Engine as part of STK Enterprise application. If you purchased ModelCenter Enterprise application but have access to the STK application separately, please contact us for access to the STK application-related features.
• Behavior Execution Engine now supports the 2021x Refresh2 version of No Magic modeling tools. See the Prerequisites topic for details on supported versions.

New features and improvements:

• Behavior Execution Engine now supports using ModelCenter MBSE or simple opaque behavior scripts to implement operations. These are alternatives to using Java delegate implementations for blocks and operations. See the ModelCenter Integration topic for more details on connecting with the ModelCenter application.
• Behavior Execution Engine now waits to check out a license until the first time you use any of its features (e.g., reports, code generation, and simulation). This enables you to use a No Magic modeling tool that has Behavior Execution Engine installed for tasks like authoring SysML without checking out a license that someone else in your organization may need for running simulations.
• Behavior Execution Engine can now run simulations opened from Teamwork Cloud. Because a project opened from Teamwork Cloud has no parent directory, project-relative paths in the model will not work. Use home-relative or absolute paths in the MoxieDelegateModulePaths and MoxieStkScenarioFromFile stereotypes instead.
• The delegate code generator now generates a Gradle build script and the SPI file for your delegate module alongside the Java source code. This helps to avoid some common mistakes when creating custom delegate modules.
• The delegate code generator now enables you to select more than one package or block to generate code for at the same time.
• The model validation report now flags call events and signal events that do not specify an operation or signal, respectively.
• The delegate availability report now lists the analysis tool controller associated with each delegate class or interface.

Breaking changes:

• Behavior Execution Engine now requires the Autostart Active Objects property of simulation configurations to be set to false. If you have any existing simulations, you will need to update this property in order to execute them with Behavior Execution Engine 2022 R2. For creating new simulations, you can use the Behavior Execution Engine Simulation Project template and Autostart Active Objects will already be set correctly.

Corrected technical issues:

• An issue with automatic delegate implementation was causing it to fail when a block operation had a parameter with both an upper multiplicity greater than 1 and a primitive SysML type. Automatic implementation now correctly translates such parameters into Java collection types.
• An issue with the delegate code generator was causing it to throw an internal modeling tool error when opened and edited multiple times. It no longer throws such errors when edited.
• An issue with the delegate code generator was causing the class implementation options to be disabled upon reopening the code generator regardless of their previous state. These options now correctly preserve their state even if you close and reopen the code generator.
• An issue with the DataProviderExecutor was causing it to fail to parse commaDelimitedElementList parameters with spaces after the commas. It now ignores such spaces.

Behavior Execution Engine 2022 R1

Announcements:

• Moxie has changed its name to Behavior Execution Engine to better describe its role in digital engineering workflows. In order to avoid major breakages, however, the SysML and Java elements that use the name Moxie are retaining their names.

New features and improvements:

• The model validation report now flags time event and change event expressions that do not resolve to compatible types for those events.
• The model validation report now flags operations that share the same name and parameter types.
• The identifier size is no longer reserved. You may now define SysML operations named size, but keep in mind that a size operation is already defined for properties with multiplicity.

Corrected technical issues:

• An issue when attempting to execute behaviors unrelated to Behavior Execution Engine was causing those simulations to fail. Now, when you execute a simulation with Cameo Simulation Toolkit or another plugin, Behavior Execution Engine will only log an info-level message instead of terminating the simulation.
• An issue when dynamically instantiating delegates with slots that defaulted to other instance specifications was causing the dynamic instantiation to fail. It now correctly instantiates any referenced instance specifications, regardless of whether they are default values or explicitly specified.
• An issue with the MoxieStkNewScenario stereotype was causing it to fail to start a new STK application instance. It now successfully starts the application.
• An issue with the MoxieTime fromIso8601String(String) method was causing it to parse local time input strings incorrectly. It now requires that the input string include both a date and a time, and that the time be specified as UTC. For example: "2001-01-01T12:34:56.789Z".
• An issue with the model validation report was causing it to incorrectly flag parenthetical expressions as errors. It now correctly parses them, checking their contents for errors.

Moxie 1.6.1

Security updates:

• Moxie has updated Apache Log4j to version 2.17.0. Log4j 2.17.0 fixes an issue with prior Log4j versions that allowed users to perform a denial of service attack from log messages. See Log4j's security fixes for more details.

Moxie 1.6.0

Announcements:

• Moxie now supports the 2021x Refresh1 version of No Magic modeling tools. See the Installation topic for details on installing the Moxie plugin to these tools.

New features and improvements:

• Moxie now supports do behaviors that execute state machines.
• Moxie now provides a DelegateInstanceManager injectable dependency that enables you to create new instances of your delegates while a simulation is running. This is especially useful for simulations that require a large number of similar objects, like a constellation of satellites.
• Moxie no longer requires the @DefaultDelegate annotation for the case in which there is only one concrete delegate implementation for a SysML block.
• Moxie now handles transitions that have triggers with unspecified event types more gracefully: logging warnings and executing the transitions as if they did not have triggers at all instead of throwing errors.

Breaking changes:

• Moxie now requires the Language type of opaque expressions to be either English or unspecified. English is the default type in No Magic modeling tools, so you likely do not need to make any updates to your models.

Corrected technical issues:

• An issue with the DataProviderExecutor was causing failures when a data interval was shorter than one second. It now can handle intervals of any size, and it even has additional options for specifying the step size or number of steps within an interval. See the DataProviderExecutor section of the STK Integration topic for more details on its usage.
• Some issues with the model validation report were causing it to incorrectly assess a few operators. It now assesses these operators correctly.
• Issues with the DefaultScalarValueminus() and within() methods and the DefaultFixedDuration isGreaterThanZero() method were causing them to return incorrect results. They now return correctly.
• An issue with BooleanEdgesSignal was causing it to still report future events after the situation changed in a way that made those events no longer occur. It now reports only events that will occur given the current situation.

Security updates:

• Moxie has updated Apache Log4j to version 2.16.0. Log4j 2.16.0 fixes an issue with prior Log4j versions that allowed users to execute potentially malicious code from log messages. See Log4j's security fixes for more details.

Moxie 1.5.0

Announcements:

• Moxie now uses Ansys licensing.

Moxie 1.4.0

Announcements:

• The ModelCenter application now has a plugin for Moxie! Using the ModelCenter application, you can now include Moxie simulations as part of workflows for requirements verification, trade-space studies, and more. For more details on the ModelCenter application, see https://phoenix-int.com/products/.

New features and improvements:

• Moxie delegates now support usage of 64-bit integers (long) in addition to 32-bit integers (int). SysML does not specify a size for the representation of SysML::Libraries::PrimitiveValueTypes::Integer.

Corrected technical issues:

• An issue with runtime code generation of list properties for Java primitive types was causing the properties to initialize incorrectly. Now properties using SysML Real, Integer, or Boolean types will work correctly with auto-implemented or partially implemented delegates. Strings and other SysML types were unaffected.
• An issue was preventing simulations from executing and the model validation report from running due to certain SysML blocks with names differing by only one character in their fully qualified names. Now those blocks are processed correctly.
• An issue was preventing the model validation report from running if it encountered elements not supported by Moxie (e.g. use case Actors). Now the validation report simply ignores unsupported elements.