Delegate Insights

This topic provides insights into the implementation and processing of delegates in the Behavior Execution Engine. It addresses the following specific areas:

 

Delegate lifecycle

When starting a simulation, the execution engine looks for all the SysML instances that are connected to the SimulationSpecification. Then, it analyzes the dependencies between those instances and attempts to create a delegate object for each one.

In the case of circular dependencies, the delegate objects may require further “wire-up” prior to simulation. The Java constructor may not have immediate access to all the slot information! During the process of creating *all* the delegate objects, each delegate object is “wired up” once all of its dependencies have been created but before any simulation takes place. Once *all* delegate objects have been created *and* wired up with values from the SysML instance slots, the execution engine then begins the parallel execution of the classifier behaviors of all the objects.

During simulation, delegate authors can also use the DelegateInstanceManager to create new delegate instances. That creation process follows the same lifecycle as above and will immediately start the classifier behavior for that object.

In summary, the delegate life sequence is as follows:

  1. Creation (calling the Java constructor)
  2. Wire-up (assigning slot information to properties)
  3. Execution (interactions driven by state machines); repeat step 1 and 2 for any new delegate instances creating during execution

Delegate methods

Some methods are common to all delegates. All delegates have access to a set of injectable dependencies provided by the core execution engine and the Analysis Tool Controller associated with the DelegateProvider for that delegate class. This provides metadata available to the execution engine through other connected analysis tools (such as STK). It also provides methods of interacting with the execution engine (StateMachineRemoteControl) and spawning new object instances at runtime (DelegateInstanceManager). For more information on STK controller delegate dependencies, see STK controller dependencies.

Delegate handling of property values

Java Delegate Classes map Java properties and operations to the corresponding properties and operations in SysML. After creating the delegate object and starting execution, the execution engine will interpret the SysML to interact with the Java code. Whenever an opaque expression in a state machine contains a reference to a property or operation in SysML, the execution engine will execute the corresponding property or method in Java.

The execution engine assigns all values from SysML instance slots by calling the setter on the Property on each delegate class prior to starting that class’s classifier behavior or executing any other behaviors.

When implementing properties or operations (Java methods) on delegates, accessing the values of type Property allows the Java code to interact with other delegate instances. These properties and operations may not have values available from within the Java constructor and are only valid in response to the execution engine retrieving or assigning a property or executing an operation (by calling a Java method).

Thread safety between BEE and the delegate infrastructure

The execution of state machines is a synchronous process that simulates potentially asynchronous behaviors for the systems under design in SysML. While the systems may be operating in parallel inside the digital simulation, the execution software ensures that all system responses happen in an ordered and precise fashion. Due to this, all execution of delegate code occurs sequentially, even though successive calls may all occur at the same simulation time instant. Any threaded or concurrent processes created within delegates must respond in sequence to the execution of properties and delegate methods simulating the retrieval, assignment, and analysis that occurs during state machine execution. They also must honor the current simulation time provided by the TimeProvider. This is contrary to many real-time co-simulation frameworks and is intended to accurately and precisely simulate complex mission systems that may often run much faster than real time but in some cases may run slower than real time to support high-fidelity physics calculations.