Creating "referenced model" that contains physical modeling connection ports

I am creating a model for the simulation of an electrical three phase system. The main-model is supposed to include a subsystem that calls another referenced model. As long as only Simulink-Signals cross the reference borders, this works fine. But I also need physical electrical signals to cross these borders, which does not not seem to be possible.

As a first solution, I tried to work with a current/voltage source at each side of the border which is controlled by a voltage/current measurement-block at the corresponding opposite side of the reference border. Different errors that came up subsequently I could get solved. But right now the model is running quite unstable. As the main model and the referenced model are running in two different time steps, the simulation crashes, as soon as the electrical values change too quick respectively the dynamic of the model states is too high.

Does anyone have any experience with this issue or dealt with a similar model and can help me with that?

Thank you very much in advance!

Best regards, Robin

Answer 1

[Sebastian Castro]

You're right that model reference boundaries don't work with physical model blocks. The reason your workaround makes the simulation crash is that you're introducing what is known as an algebraic loop in Simulink.

Essentially, by adding Simulink signals at the model boundary, you're "tricking" Simulink into thinking one network's inputs are directly dependent on its outputs. This, in turn, forces Simulink to "guess" the solution through an iterative solution. Generally not a good thing to have if you can avoid it.

A better workaround in my opinion would be to change the model references to libraries. With libraries, you can still split up your design into separate files, create single-sources reusable components, etc. However, physical connection ports can be at the interfaces of library blocks.

The downside of using libraries is that, by keeping all blocks in the same physical network, they all must have the same sample time. Were you trying to run different parts of your model at different rates? If so, I'd stick with your original approach and place a Transfer Fcn block in the loop as a low-pass filter to break the algebraic loop. This requires some manual tweaking that is highly dependent on your model dynamics.

- Sebastian

[RobinZ]

I prefer to call a model reference rather than using the library option. Right now I am breaking the algebraic loop with a unit delay. This works fine to compile and run the model. But as soon as there are very dynamic changes in the electrical values, the simulation interrupts (no error message). Sadly I cannot do any adjustments with the "unit-delay-block".

What kind of "transfer-fcn-block" did you mean to use exactly to break the loop? My model is using a fixed-step discrete solver. The "discrete-filter-block" does not seem to break the loop.

Thank you very much for your help!

[Sebastian Castro]

Why do you prefer using model references over libraries? Do you have other requirements that warrant model references? Because if not, I'd strongly recommend doing away with the Simulink signals so you do not have these solver issues.

Again, if you absolutely HAVE to, the other solution would be to break the algebraic loop. Unit Delays are not very good as they change the system dynamics. You can either use a Transfer Fcn or a Discrete Transfer Fcn block and configure it so that you aren't filtering out any of the important dynamics of the system.

Lastly, why is the entire model set to Fixed-Step Discrete? Do you plan on generating code from the electrical model? Also, if this is the case, is your powergui set up so the SimPowerSystems network is also discrete (I'm guessing it is)?

- Sebastian

[RobinZ]

Hello Sebastian! Yes, my powergui-block is set to fixed-step discrete as well. As mentioned, the discrete-filter block did not break the algebraic loop, but the discrete-transfer-fcn did the job! Now I just need to work on it´s configuration. Thank you very much for your help :) BR, Robin