Namespace TimeSeriesAnalysis.Dynamic

Classes

ClosedLoopUnitIdentifier

Identification that attempts to identify a unit model jointly with estimating the additive signal acting on the output(disturbance signal) yet is counter-acted by closed-loop (feedback)control, such as with PID-control.

The approach requires combining information in the measured output signal with the information in the manipulated variable(determined by active control) that is inputted into the process

In order to accomplish this estimation, the process model and the disturbance signal are estimated together.

Comment

Class that holds comments added to models.

ConnectionParser

Class that tracks which model is connected to which in a set of models.

This is important when traversing the models when simulating with the PlantSimulator, as these models need to be run in a specific order

DisturbanceCalculator

For a given process model and dataset, calculate the disturbance vector d by subtracting y_proc from y_meas

DisturbanceIdResult

Internal class to store a single sub-run of the DisturnanceIdentifierInternal

Divide

Simulatable divide block, requires exactly two inputs

DivideParameters

Paramters of the divide model

FittingInfo

Be careful as the objective function is different for the static estimation that considers the absolute values, while dynamic estimation considers "diffs"- for this reason it is best to use RsqDiff and RsqAbs when comparing different model runs which can be a combination fo static and dynamic

FittingSpecs

Class that contains variables that are specified prior to fitting, such as working point, minima and maxima.

GainSchedFittingSpecs

variables that are set prior to fitting.

GainSchedIdentifier

Attempts to identify a gain-scheduled model, a model that uses multiple local linear models to approximate a nonlinearity. Should not be confused with gain-scheduling in terms of PID-control.

GainSchedModel

Simulatable gain-scheduled model.

A model for systems that cannot be adequately modelled by UnitModel,because they either have time constants or gains or both that vary signficantly depending on the value of one of the inputs.

One input is selected as the "scheduling varible" and one ore more thresholds are given for this scheduling variable. The thresholds can be set indepently for time-contant and linear gain.

Remember that with more thresholds defined, the higher the requirement for information content in data will be if the model is to be identified from it.

This should not be confused with "gain-scheduled" PID-control, which is a similar concept but applied to PID-control parameters.

GainSchedParameters

Parameters data class of the GainSchedModel

ModelBaseClass

Abstract base class that contains common functionality across all models which are to be implemented. ISimulatableModel

ModelParametersBaseClass

Abstract base class for ISimulatableModel classes

PidAntiSurgeParams

Class that contains special pid-controller parameters for anti-surge controllers PidModel PidController

PidController

Proporitional-Integral-Derivative(PID) controller

that supports

first and second order low pass filtering of process variable
anti-windup
bumpless transfer between auto and manual mode
"warmstarting" -bumpless startup
feedforward
scaling of input and output values
gain scheduling of Kp
gain scheduling of Ti
"kicking" as is usually applied to compressor recycling controllers/anti-surge
min select/max select (also referred to as high select or low select: (multiple pid-controllers controlling the same output switch between auto and tracking mode)

By design decision, this class should be kept relativly simple in terms of coding patterns, so that it is possible to hand-port this class to other languages (c++/c/Structured Text/Labview/Matlab etc). To simulate PID-control, use the wrapper class PIDModel, as it wraps this class and impelments the ISimulatableModel interface needed to simulate with ProcessSimulator

PidModel

PidFeedForward

Parameters describing PID-controller parameters for feed-forward PidModel PidController

PidFilter

Class that handles the filtering of inputs y to a pid-controller Put into separate class as this is both a component of the PidController and of PidIdentifier, and important that implementation is equal.

PidFilterParams

Containing the information related to how a pid-controller should low-pass filter its input signal

PidGainScheduling

Parameters describing PID-controller parameters for gain-scheduling PidModel PidController

PidIdentifier

Class that attempts to identify the parameters (such as Kp and Ti) of a PID-controller from a given set of time-series of the input and output of said controller.

PidModel

Simulatable industrial PID-controller

This class is as a wrapper for PidController class, that implements ISimulatableModel.

To simulate minimum or maximum select controllers, combine this class with Select blocks.

The controller paramters belong to different aspects of the controller like, tuning, scaling, gain-scheduling, feedforward and anti-surge are adjusted have been collected into a number of data-classes, linked below:

PidParameters PidAntiSurgeParams PidFeedForward PidGainScheduling PidStatus PidScaling PidTuning

PidParameters

Parameters of the PIDModel PidModel PidController

PidScaling

Parameters describing PID-controller parameters for scaling PidModel PidController

PidTuning

Parameters describing PID-controller tuning (Kp,Ti,Td)

PidModel PidController

PlantSimulator

Simulates larger "plant-models" that is built up of connected sub-models that each implement ISimulatableModel.

To set up a simulation, first connect models, and then add external input signals. This class handles information about which model is connected to which, and handles calling sub-models in the correct order with the correct input signals.

By default, the model attempts to start in steady-state, intalization handled by ProcessSimulatorInitializer (this requires no user interaction).

The building blocks of plant models are UnitModel, PidModel and Select

UnitModel PidModel PlantSimulatorInitalizer Select

PlantSimulatorHelper

Convenience functions for using PlantSimulator

PlantSimulatorInitalizer

Intializes a plant simulator in the first data point

Currently, only initalizing to steady-state is supported.

By design choice, this class traverses the models by logic to initialize the plant model rather than using mathematical programming/matrix solvers.

PlantSimulatorSerializer

Deals with loading a PlantSimulator from file

Select

Simulatable select block

This block can function either as "minimum" or "maximum" selector, mainly inteded for simulating "min select" or "max selct" pid-control by combining with PidModel

SerializeHelper

Quickly serialie both plantSim and data associated with it.

SignalNamer

Handles naming of individual signals in a process simulation

TimeDelay

Delays a signal by a specific number of time steps, keeping an internal buffer of delayed values between iterations.

This is a reasuble class for providing time-delay functionality to simulatable models.

TimeDelaySamples

Delays a signal by a specific number of time steps, keeping an internal buffer of delayed values between iterations.

This is a reasuble class for providing time-delay functionality to simulatable models.

UnitDataSet

The data for a porition of a process, containg only one output and one or multiple inputs that influence it

UnitIdentifier

Identifier of the "Default" process model - a dynamic process model with time-constant, time-delay, linear process gain and optional (nonlinear) curvature process gains.

This model class is sufficent for real-world linear or weakly nonlinear dynamic systems, yet also introduces the fewest possible parameters to describe the system in an attempt to avoid over-fitting/over-parameterization.

The "default" process model is identified using a linear-in-parameters parameterization (parameters a,b,c), so that it can be solved by linear regression and identification should thus be both fast and stable. The issue with the parameterization (a,b,c) is that the meaning of each parameter is less intuitive, for instance the time constant depends on a, but linear gain depends on both a and b, while curvature depends on a and c. Looking at the unceratinty of each parameter to determine if the model should be dynamic or static or what the uncertainty of the time constant is, is very hard, and this observation motivates re-parameterizing the model after identification.

When assessing and simulating the model, parameters are converted into the more intuitive parameters "time constant", "linear gains" and "curvature gain" which are a different parameterization. The UnitIdentifier, UnitModel and UnitParameters classes handle this transition seamlessly to the user. Uncertainty is expressed in terms of this more intuitive parameterization, to allow for a more intuitive assessment of the parameters.

Another advantage of the parameterization is that the model internally separates between steady-state and transient state. You can at any instance "turn off" dynamics and request the steady-state model output for the current input. This is useful if you have transient data that you want to analyze in the steady-state, as you can then fit the model to all available data-points without having to select what data points you believe are at steady state, then you can disable dynamic terms to do a static analysis of the dynamic model.

Time-delay is an integer parameter, and finding the time-delay alongside continuous parameters turns the identification problem into a linear mixed-integer problem. The time delay identification is done by splitting the time-delay estimation from continuous parameter identification, turning the solver into a sequential optimization solver. This logic to re-run estimation for multiple time-delays and selecting the best estimate of time delay is deferred to TimeSeriesAnalysis.Dynamic.UnitTimeDelayIdentifier.

Since the aim is to identify transients/dynamics, the regression is done on model differences rather than absolute values.

UnitModel

Simulatable "default" process model.

This is a model that can be either dynamic or static, have one or multiple inputs and can be either linear in inputs or have inputs nonlinearity described by a second-order polynominal. Dynamics can be either 1. order time-constant, time-delay or both. The model also supports "additive" signals added to its output (intended for modeling disturbances).

The model is designed to lend itself well to identification from industrial time-series datasets, and is supported by the accompanying identification method UnitIdentifier.

This model is also intended to be co-simulated with PidModel by PlantSimulator to study process control feedback loops.

It is assumed that most unit processes in industrial process control systems can be described sufficiently by this model, and thus that larger plants can be modeled by connecting unit models based on this model structure.

It would be possible to extend this model to also describe second-order dynamics along the same principles by the introduction of one additional parameter in future work.

UnitParameters

Parameters data class of the UnitModel.

UnitSimulator

Stand-alone simulation of any ISimulatableModel model.

Interfaces

ISimulatableModel

Generic interface that any process model needs to implement if it is to be simulated by PlantSimulator.

Namespace TimeSeriesAnalysis.Dynamic

Classes

Interfaces

Enums