Process gain in System Identification seems off by 100

Hello,

Running a simple first order test process through System Identification, to make sure I understand the results.

The .mat file is attached with data, after which I import into a iddata.

The output of my data changes from 1000 down to 0 (data does not run far enough to get all the way to 0) and the input changes from 6 to 5.

I would expect a process gain of 1000 / 1 = 1000. However, SI is giving me 10?

Time constant is correct at 0.71sec. Delay is correct at 0.

load ("data.mat", "import");

model = iddata(import.out, import.co, 0.001)

[Kurt]

Just for confirmation, I have attached a screeshot from PIDtuner, which is correctly characterizing the time delay and process gain.

Is this not an unexpected System Identification result?

[Kurt]

No ideas from the community, or am I posting with the wrong tags?

Data is there to run, just interested in if I am using the software correctly...

[Mathieu NOE]

hello

you make your calculations your way , which is maybe not how SI interpret your data , or the way you give data to matlab (and also SI does not know if your output is going to really go down to zero, only you know that)

in other words you compute the plant DC gain based on the variations (so delta output vs delta input )

are you sure the SI functions in your code are working on the delta 's ?

second remark : how can you fit a first order (with delay) low pass model to an output that goes down to zero (with a certain decay rate) vs an input that remains constant and non zero (asymptotic value = 5); if that was correct we should see the output tend towards DCgain*5 = rougly 5000 with your calculations - so there is quite an issue here with the fact that the output is going down towards 0

if an output drops to zero whatever the (constant) asymptotic input value, there must be a zero in the numerator.

Answer 1

[Rajiv Singh]

Models have an additional degree of freedom coming from initial conditions. For your data, this interplay means that there is no unique answer. Note that by default the initial conditions are estimated too as part of the fitting process.

For unambiguos results, I would suggest performing an experiment where the output is at a stead-state for constant input, before the input is changed to a new value. That way you can fix the initial conditions to a known fixed value.

Answer 2

[Kurt]

After further investigation, I believe I have some progress.

To Mathieu-

I am certain of my data being %CO and %PV and that they are accurate. I made the data myself from a known plant, as the goal is to prove if I am using SI correctly. There is no problem with the data, it is a known process. I am not sure what you are implying by requiring a zero in the numerator. Again, the process is known, and it is a first order decay. Nothing unreasonable about the output being zero with a non-zero input. Until I can get SI to agree with me that my known first order decay is indeed that with the correct constants, I am not using SI correctly. But the raw data is correct.

I was suspecting there is a difference between 'transfer function' and 'process model' in SI, and while it makes sense the data does not fit well into a straight transfer function, the process model needs to deal with changes. Therefore, my guess is that the data, while correct, is not being processed by SI as changePV/changeCO, hence the problem.

To Rajiv-

The first data point in the .mat is the intial condition, so I have done what you suggest already.

I tried preprocessing the data set with mean removal, and that did not work. My latest attempt was to do the following to my raw data:

opts = detectImportOptions("data.xlsx");
opts.SelectedVariableNames = ["co", "out"];
rawdata = readtable("data.xlsx", opts);
offset = rawdata{1, "co"}; % OFFSET OF CONTROL OUTPUT
offset2 = rawdata{1, "out"}; % OFFSET OF PV OUTPUT

% MAKE NEW TABLE WITH ONLY THE CORRECTED DATA NEEDED
refdata = table;
refdata.co = rawdata.co - offset;
refdata.out = rawdata.out - offset2;

TT = table2timetable(refdata, 'TimeStep', seconds(0.001));

model = iddata(TT);
% SELECT THIS MODEL AS AN OBJECT IN SYS IDENT APP

This appears to work correctly. So I have to manually remove offset, starting both the CO and the PV at zero, in order to get a correct characterization of the process model. This seems unnecessary, that SI should do this for me as part of the process model selection. Basically, I am having to take real data from a physical process, and manually force it to offsets that SI wants to work with in order to get the actual process model.

SI gets 100% fit to the input data, with correct values based on the known process. So, as I suspected, it does not require the output decay fully to zero - SI can still see clearly the process is first order.

I think at this point, it is certain the data is good data, and SI can correctly calculate the constants. So we can avoid discussion of "are you certain the data is good".

Why must I perform these extra manual steps with SI when PIDtuner does not require it? Is there a pre-processing function that would help (remove means does not work).

[Mathieu NOE]

hello again

@Kurt

I never said that your data are not correct or accurate I fully trust them

but I can't find out how a "standard" first order model could match this : Nothing unreasonable about the output being zero with a non-zero input.

unless the dc gain is zero , please explain me this again....

or maybe it's because it's monday and my brain haven't started yet....

Answer 3

[Kurt]

Not sure if this helps, but attached is a screen shot of what I am capturing. The data is in COMTRADE format, so I can export to a .csv if you need, but the original post contains this same data in the .mat file. What I did in the .mat file was preload the first sample where STATE=6 with 1000, as I am aware the step in green is not part of what I am trying to model. I only am modeling the first order decay.

I know for certain the characteristic is first order, because I made the PLC create this curve. What I am attempting to obtain from SI is the change in STATE (6 to 5) vs the change in SP_EXCITATION (1000 to 0). Although in this case I have a known time constant of 0.71sec, I am only trying to prove I am using SI correctly if it gives me that time constant.

Gain should be 1000/1 = 1000. According to SI it is 10? Obviously I am missing something in the data provided to SI.

After 2 seconds, the PLC takes over the green plot, and the first order decay no longer applies. This is why I stated originally that my data does not actually go to 0, even though internally the first order program does in fact have a final output of 0. My data capture stops at 2 seconds as provided to SI. I do know SI is able to know this is a first order based on a partial capture; it does not require a final datapoint of 0.

I don't know if we are talking apples to apples, but in process control I can have a non-zero input (to the field of a generator) and yet have a zero output for a process value (reactive power output). I am not modeling a mathmatical transfer function; I am modeling a physical system. This is why the change of values is so important in calculating the gain.

Once I start using SI for the other unknown processes in my system, my inputs will vary quite significantly (not just a change of state by integer values) so I need to know how to get it to provide the parameters accordingly. Running the PLC in manual mode and applying step changes to processes is a fundamental need to modeling these physical systems.

[Mathieu NOE]

hello again

if you trust your identification process, have you tried to simulate your identified model and compare it to the real data ?

[Kurt]

Yes, I have had the model in Simulink for months now in preparation, and it behaves exactly as I am expecting.

As long as I apply the manual corrections with 'refdata' posted above, all is well. But why must I do that?