Hi Juan,
I understand you have concerns about Simscape Electrical Specialized Power Systems through ARTEMiS.
1. Using ARTEMiS and Distributed Parameter Lines to Connect Subsystems
Yes, you can use ARTEMiS and a distributed parameter line to connect the subsystems.
In standard RT-LAB workflows, Simscape physical connection lines (LConn / RConn ports) cannot directly cross subsystem boundaries because the RT-LAB OpComm block only handles standard Simulink signals.
However, ARTEMiS transmission line blocks are specifically designed to enable multi-core execution:
Decoupling mechanism: The ARTEMiS Distributed Parameters Line (DPL) and ARTEMiS Stubline use Bergeron’s traveling-wave method. Because a transmission line has an intrinsic physical propagation delay (\tau \ge \Delta t), the state-space equations on both sides of the line become mathematically independent at any given time step.
RT-LAB configuration: You can place the ARTEMiS line block at the root level of your Simulink model and connect its physical modeling ports directly to the respective top-level subsystems (e.g., SM_Master and SS_Slave). RT-LAB automatically handles the inter-core communication for these blocks without requiring OpComm on the physical lines.
2. π-Section Lines in ARTEMiS and Splitting Alternatives
ARTEMiS does not provide a decoupling π-section line block.
Why π-sections cannot decouple: A π-section line is a lumped-parameter model with zero propagation delay. It introduces immediate algebraic/state coupling between the two sides of the line, which means it cannot split state-space matrices across cores on its own.
How to model lines when splitting:
ARTEMiS Stubline / Compensated Stubline: If the line is short (where the real physical travel time is less than one simulation step \Delta t), use the ARTEMiS Stubline or ARTEMiS 3-phase Coupled / Compensated Stubline (found in ARTEMiS/Tools/Decoupling Blocks). Stublines enforce an artificial 1-step delay (\tau = \Delta t) to allow subsystem decoupling, while the Compensated Stubline mathematically cancels the added parasitic capacitance at fundamental frequency.
ARTEMiS Distributed Parameters Line (DPL): For long lines where the propagation travel time \tau \ge \Delta t, replace the π-section line with the ARTEMiS DPL block.
Keep the π-section inside a single subsystem: If you must use standard Simscape SPS π-section blocks, keep the line and its immediate adjoining components within the same subsystem/core, and place the multi-core decoupling boundary elsewhere (e.g., at an ARTEMiS Stubline or DPL).
3. Splitting Across Cores Without ARTEMiS
There are also other ways to split your model if you do not have an ARTEMiS license or prefer native Simscape SPS blocks, such as:
A. Controlled Sources with 1-Step Delay (Ideal Transformer Method / ITM)
Measure voltages and currents at the interface in Subsystem 1 using SPS Voltage/Current Measurements.
Route these measurements as standard Simulink signals through an explicit Unit Delay (z^{-1}) block and an OpComm block into Subsystem 2.
Recreate the electrical interface in Subsystem 2 using SPS Controlled Voltage Sources or Controlled Current Sources (and vice-versa).
Note: Introducing an artificial 1-sample delay into an electrical mesh can cause numerical oscillations or stability issues. Adding small RC damping filters or placing the interface across inductive/capacitive boundaries helps maintain numerical stability.
B. Decoupling Across DC Links / Energy Storage Elements
If your model contains a power electronic converter with a large DC-link capacitor or inductor, split the model at the DC bus:
Subsystem 1 calculates the DC link voltage and sends it (via OpComm with delay) to Subsystem 2.
Subsystem 2 calculates the injected current and sends it back to Subsystem 1.
The large physical time constant of the DC capacitor acts as a natural buffer, making this interface much more stable than AC-side controlled source decoupling.
C. Control vs. Plant Separation (Functional Decoupling)
Keep the entire electrical power network (SPS Simscape circuit) on a single real-time core (inside SM_Master).
Move controllers, PWM generators, PLLs, measurement processing, grid-code logic, and communication protocols into separate secondary cores (SS_Slave1, SS_Slave2, etc.).
These communicate purely via standard Simulink signals passing through OpComm blocks.
Hope these help.