Overview

This document provides a high-level overview of the different components that make up Ansys Behavior Execution Engine.

Figure 1: What does Behavior Execution Engine include?

The Execution Engine

The execution engine ingests, interprets, and instantiates your formal models and embeds them into a simulated physical environment, modeled by an analysis tool such as STK. It uses patented AGI technology to coordinate time across all objects in the simulation as events take place. In other words, it does not use a discrete timestep to move the simulation forward, and instead it coordinates multiple clocks to ensure that all systems and sub-systems exist accurately and precisely in the same simulated universe. To learn more about how Behavior Execution Engine coordinates time, take a look at the introductory section of the Events help topic.

Analysis tool integration

Analysis tools such as STK, finite element tools, and proprietary system response software are excellent at modeling complex physics environments precisely. Behavior Execution Engine leverages these tools to model the time-dynamics of simulated systems. As Behavior Execution Engine coordinates events between state machines, it manages the exchange of data with your custom Java delegates, which in turn interact with your analysis tools. Delegates are the key component of Behavior Execution Engine's dependency injection architecture, enabling you to inject custom code to be executed in conjunction with time events, change events, and guards.

This integration of responsibilities and customizable execution enables you to focus on system design without the burden of modeling the physics environment. For example, you can simulate the interaction of systems modeled at different time scales, using different analysis methods, without requiring them all to participate in the same numerical integration. Furthermore, you can correlate these events to the associated analysis tools' output (reports, visualizations, etc.), highlighting key behaviors warranting further investigation.

Behavior Execution Engine also provides a way for you to integrate with ModelCenter to execute workflows or trade studies that connect to analysis tools using ModelCenter's components instead of Java delegates. You can even use the Behavior Execution Engine component in ModelCenter to run a simulation as part of a workflow or trade study.

Delegates and delegate modules

A delegate is a Java interface or class that represents a one-to-one correspondence between itself and a block in your model. A delegate class contains custom code that implements the properties and operations of a block. This code is executed when the opaque expressions in state machines are evaluated at simulation runtime. Though any arbitrary Java code may exist inside a delegate, you reap the true benefit of Behavior Execution Engine when you use delegates to integrate the analytical rigor of physics-based analysis tools to precisely drive state machine transitions in a simulation.

Collectively, all delegates used for a particular analysis tool are referred to as a Delegate Module.

Behavior Execution Engine also enables you to have two or more delegate implementations for any given block. Depending on the application, these implementations may contain entirely different logic or even use different analysis tools. You may then specify which implementation to use for each Instance Specification by applying the appropriate stereotype. For more information, see the Stereotypes help topic.

For a comprehensive guide to developing delegates and using them in your simulations, see Developing Delegates.

Reports and utilities

Model validation report

The model validation report runs a validation process against your state machines and the model elements referenced within them. This checks whether the opaque expressions that reference properties and operations are in agreement with their corresponding blocks and delegates, and that they are compatible with Behavior Execution Engine. The validation process looks for naming inconsistencies, invalid access usages, incorrect return types, and many other issues.

When the process is finished, it presents you with a list of detected errors and warnings in your default text editor. Each error and warning in the report is paired with the ID and qualified name of the offending element in your model. Use this tool early and often when developing your simulations to identify issues all at once, so you can correct them prior to execution. You can find the model validation report in the Diagnostics page.

The model validation report will not always catch everything that could go wrong with your simulation. Sometimes there may be a configuration error or a bug in the delegate code that causes your simulation to fail at runtime. In this case, the best place to look is in the simulation log file.

For more details, see the Model Validation help topic.

Delegate availability report

The delegate availability report shows the canonical Java class names of the delegate and delegate modules that the current simulation will load. This report helps to verify that the delegate modules have been deployed correctly and do not conflict with each other when multiple modules are loaded together. In addition, it shows the qualified name of the block each Java class represents. You can find the delegate availability report in the Diagnostics page or in the Actions menu.

Block usage report

The block usage report lists all properties and operations currently in use by the state machines defined within your simulation. With this information, you can identify missing state machine elements or determine whether or not an element is referenced incorrectly. You can find the block usage report in the Diagnostics page.

Delegate code generator

The delegate code generator utility generates Java interfaces and classes based on your model that are compatible with the Behavior Execution Engine delegate architecture. You can find the delegate code generator in the Code Generation page.

For more details, see the Delegate Code Generation help topic.

Runtime code generation

As your simulation executes, Behavior Execution Engine automatically generates default delegate implementations for model types that do not require custom implementation.

Model libraries

Behavior Execution Engine includes three model libraries: a required base for all simulations, a geometry core that you can extend for specific domains, and a helper for connecting to STK.

Balloon Ride reference application

Behavior Execution Engine includes a sample reference application depicting a simplified one-dimensional hot air balloon ride. This sample will help you understand how the pieces of Behavior Execution Engine fit together without having to deal with complicated physics or to integrate external tools. You can find the SysML project and the associated delegate source code in the \samples\balloonRide directory of the installation. You can open the Behavior Execution Engine Installation Directory directly from the Windows Start menu or Taskbar search box.

Tutorials

The Behavior Execution Engine tutorials will guide you through applying the above concepts to create and utilize a complete Behavior Execution Engine simulation from the ground up. The tutorials are broken up to give you the flexibility to practice individual concepts without having to step through everything from the very beginning.

For more details, see the Tutorials.

Moxie legacy

As you begin to use Behavior Execution Engine, you will quickly discover many references to Moxie. Behavior Execution Engine was formerly named Moxie and has retained the usage of the name Moxie in its SysML and Java elements in order to avoid major breakages.

Interoperation with No Magic Modeling Tools

Behavior Execution Engine and previously Moxie both had plugins into the Cameo (MagicDraw) SysML tools from No Magic. However, as of 2023 R2.1, we have removed those plugins to pursue a more product independent and interoperable execution capability.

As our customers continue to implement model-based systems engineering solutions, we realize that every organization presents unique challenges in the way their engineers and designers work together and the tools they rely on. We recognize flexibility enables disparate software tools to share data and interoperate, and that is why our product strategy has focused on open APIs and interoperability.

In alignment with this product strategy, as of the 2023 R2 release, Behavior Execution Engine (BEE) has taken some necessary steps to rearchitect how it interacts with SysML modeling tools. In particular, we are moving to offer a more open and flexible way for our customers to leverage the behavior modeling capabilities. Now, BEE can execute independently, no longer requiring the use of a Cameo process. This allows you to author SysML using the Cameo authoring environment but to then reference those system architecture model project files directly from your own software platforms without needing Cameo to execute. This provides more collaboration options by loading the system model projects (e.g. the 'mdzip' file) directly, and it also unlocks scalability opportunities for customers needing to analyze larger design trade studies or even integrate directly into other engineering tools.

We know these are necessary steps in unlocking the full potential of behavior modeling across the growing portfolio of Ansys tools, and we look forward to bringing even more exciting new features to BEE users in our upcoming releases.

Thank you.
Ansys Product Management