Namespace TimeSeriesAnalysis.Dynamic

Classes

BadDataFinder: For dynamic model identification in system identification, bad data points will create "spurious dynamics" that it is especially important to filter out, otherwise it may destroy identification of dynamic terms.

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.

CommonDataPreprocessor: Common logic that is to be shared among PlantSimulator and different Identification algorithms, to choose data points that are to be ignored when either simulating or identifying or both.

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

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.

FrozenDataDetector: Determines if all data has frozen for any samples

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.

See also: GainSchedParameters

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, initialization handled by ProcessSimulatorInitializer (this requires no user interaction).

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

UnitModel PidModel PlantSimulatorInitializer Select

PlantSimulatorHelper: Convenience functions for using PlantSimulator

PlantSimulatorInitializer

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 serialize both PlantSimulator object 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 reusable class for providing time-delay functionality to simulateable models.

UnitModel

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.

Interfaces

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

Enums

DisturbanceEstimationError: Enum describing reasons that a disturbance may be set by logic to exactly zero

GainSchedIdentWarnings: Enum of recognized warning or error states during identification of process model

GainSchedWarnings: Enum of recognized warning or error states during identification of process model

INDEX: Enum to provide more readable code, for the input instance (int)INDEX.FIRST may be more readable than "0"

ModelType

Enum of recognized types of unit-models.

This type is used to set the unit model unique identifier and is also used in internal logic in the large-scale dynamic simulations

PidControllerType: The type of PID-controller.

PidIdentWarning: Warnings that arise during identification of PidModels

PidModelInputsIdx: This determines the position in the U-vector given to Iterate for the class PIDModel

PidStatus: Enum to classify the status output of PidController.cs

ProcessTimeDelayIdentWarnings: Enum of recognized warning or error states during identification of time delays

SelectType: An enum of the type of Select model

SignalType: Enum of types of signals that ProcessSimulator must differentiate between

UnitdentWarnings: Enum of recognized warning or error states during identification of process model

Table of Contents

Namespace TimeSeriesAnalysis.Dynamic

Classes

Interfaces

Enums