viproma/coral

Cache output variable values after step

Opened this issue · 0 comments

When a STEP command is complete, Coral should retrieve all relevant output variable values from the slave instance into a cache, and the cache should not be updated before the next STEP command is complete. Specifically, a RESEND_VARS command should use the cached values, and not retrieve them from the slave instance like today.

The reason is to prevent a subtle issue where the outputs could change without a time step having been performed, due to a system reconfiguration (i.e., when variable values or connections are changed by the master).

Here is an example scenario with two slaves:

  1. Master sends STEP to slaves 1 and 2; both slaves perform time steps and publish their output values.
  2. Master sends ACCEPT_STEP to slaves 1 and 2; both slaves receive output values from the other.
  3. Master sends SET_VARS to slave 1; the slave changes one or more of its inputs, and in our pretend scenario this causes one or more of its outputs to also change immediately (e.g. because the variables are aliased).
  4. Master sends RESEND_VARS to slaves 1 and 2 (because this is what it does when the system configuration changes); both slaves publish output values and receive input values.

After that last step, slave 2 now has a new input value even if no new time step has been performed.

Or actually, it may or may not have a new input value. As it turns out, this highly dependent on timing and ordering. Unlike the value exchange which happens after a STEP, where the reception and acceptance of values is synchronised by the ACCEPT_STEP command, a RESEND_VARS command will cause the slave to send and receive values in quick succession. The first slave to receive RESEND_VARS will probably not get the values from the second, because it sees that it already has a full set of values from the last time step (received in the ACCEPT_STEP stage).

Caching would solve all this.