The signal generator is an entity, that instantiates a discrete model, manages its lifetime and steps it based on the incoming device events.
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_Downdevice 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
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
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.
A signal generator operates in a synchronous mode, when:
Synchronize_To_Signalis set to
Synchronization_Signalis set to a valid signal GUID or
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,
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,
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
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
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.
A signal generator operates in an asynchronous mode, when:
Synchronize_To_Signalis set to
Maximum_Timeis set to a valid value greater than the
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
event, if the
Shutdown_After_Last is set to
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.