Signal generator

The signal generator is an entity, that instantiates a discrete model, manages its lifetime and steps it based on the incoming device events.

Configuration

• Model (GUID) - a GUID of a discrete model to encapsulate
• Feedback_Name (string) - a string representing the name of the feedback link
• Synchronize_To_Signal (boolean) - if set, the stepping of the model will be synchronized to device events containing signal with specified GUID (see the next line)
• Synchronization_Signal (GUID) - if the previous parameter is set to true, this is the GUID of the signal to synchronize to
• Time_Segment_Id (integer) - ID of a time segment to emit when operating in the asynchronous mode
• Shutdown_After_Last (boolean) - when operating in the asynchronous mode, should we emit the Shut_Down device event after the last step?
• Stepping (time) - the model will be stepped with this period of simulated time (regardless the actual time spacing of incoming events, when synchronized to a signal; see below)
• Maximum_Time (time) - when operating in the asynchronous mode, how much time should we simulate?
• Echo_Default_Parameters_As_Event (boolean) - if set to true, configured parameters are emited as a device event when configured
• Individualize_Segment_Specific_Parameters (boolean) - if set to true, the signal generator will work with segment-specific parameters independently for all segments
• Parameters (double array) - configured model parameters as a concatenated array of lower parameter bounds, default parameters and upper parameter bounds

Supported interfaces

• scgms::IFilter_Feedback_Receiver

General function

The purpose of the signal generator entity is to operate a discrete model in either synchronous or asynchronous mode. The synchronous mode is selected, when the Synchronize_To_Signal is set to true and other related fields are set to a valid value.

The signal generator calls Initialize method of the encapsulated model depending on the configuration. See the specific modes of operation below.

When the signal generator performs a step operation on the model (the model is stepped), the internal timer is incremented by the Stepping value and the Step method of the encapsulated model is called with the time delta. As the stepping parameter is configured once, the stepping parameter passed to the model is constant. However, in general, this is not an interface requirement - it is always true only when using a model encapsulated in a signal generator.

Synchronous mode

A signal generator operates in a synchronous mode, when:

• Synchronize_To_Signal is set to true
• Synchronization_Signal is set to a valid signal GUID or scgms::signal_All

Every time a device event containing a level of the specified signal (Synchronization_Signal) passes through the signal generator filter, the internal model may be stepped. The first time such an event passes through, the Initialize method of the model is called. Every other time, the filter increments the internal timer, and if the value delta reaches (or exceeds) a multiple of the stepping value, the model is stepped. For example, when the Stepping value is set to 5 minutes, first level comes at time t and the next level comes at time t+12 (minutes), the model is stepped exactly twice, so the current internal time of the model is now t+10. When a next event reaches the filter at time t+15, the model is stepped once to reach the multiple of stepping value.

The signal generator instantiates multiple models, one for each time segment. This means, that each model instance operates independently for every time segment. This also allows for segment-specific parameters to come into action, as every model might have its own set of parameters, that can be optimized individually using a solver. To achieve this, the model needs to have segment-specific parameter count set to a valid value. The rest is managed by the SmartCGMS system.

This mode of operation is useful when a model must rely on another signal as a synchronization source. We may take an insulin pump controller adjusting the basal insulin dosage as an example. The model changes the output if and only if a newer value of the interstitial glucose signal is available.

Another example would be an educational tool, when a controlled stepping is desired. For example, we use one of the available metabolism models, then we set the Stepping to 5 minutes and we synchronize the model to a scgms::signal_Synchronization, which serves as a control signal only. Then, we start the chain and start a new timer thread in the outer code (e.g. to fire every second). Every time a stepping is desired, we send a scgms::signal_Synchronization signal event through the chain.

The diagram above illustrates the model stepping when variable time spacing occurs in the control signal series. The time is denoted in minutes for simplicity, although the actual values are represented as a rat time.

Asynchronous mode

A signal generator operates in an asynchronous mode, when:

• Synchronize_To_Signal is set to false
• Maximum_Time is set to a valid value greater than the Stepping value

The signal generator creates a separate thread for the model, in which it steps the model with the fixed stepping until the Maximum_Time is reached. Once it reaches this limit, it may emit the Shut_Down event, if the Shutdown_After_Last is set to true.

This mode of operation is useful when there is no control signal to synchronize to. It basically implies, that the model outputs are based solely on the model (and filter) configuration, and does not take any other events into account.

An example of the asynchronous model use may be a "scenario generator", that creates a test scenario based on its parameters. Such a model does not take any other inputs. Usually, a synchronous signal generator (embedding a patient model) synchronized to all signals (scgms::signal_All) follows in the filter chain, so the dynamically generated test scenario could be evaluated.