model_refe​renceブロックを​利用したコアモデル（​≒汎用モデル）活用時​のIFに関して

現在、「バッテリー＋充放電器」で構成されるシステムモデルを作成しています。

バッテリーは特定機種で様々な充放電器モデルに接続した場合の特性把握を行おうとしています。

そのため、バッテリーモデルはコアモデルとして作成しておき、システムモデル側では「model_referenceブロックで参照」とすることで汎用性を高めたモデル管理にしたいと考えています。

バッテリーのコアモデルはキャプチャ１にあるように、電気ドメインである＋/－端子をIFとする非因果モデルで構築しています。

一方で、この場合、model_referenceブロックはSimscape端子をIFと認識できないようで、キャプチャ２にあるようにモデル参照を行うと最外サブシステムにIFが出てこない状態になってしまい、どの充放電器モデルとも接続できずに困っています。

バッテリーモデルを汎用モデルとしつつ、電気ドメインIFを持つ充放電器モデルたちと接続できるようにするための適切な処置・方法があればご教示頂けないでしょうか。

＜キャプチャ１＞　　　　　　　　　　　　　　　　　　　　　　　　　　＜キャプチャ２＞

　

Answer 1

[Ritam]

I have assumed that you want advise on an appropriate approach or method to keep the battery model as a generic model while allowing it to connect to charger/discharger models that have electrical domain interfaces.

Model Reference blocks in Simulink are designed for signal-based interfaces, so they do not natively expose Simscape conserving ports like electrical +/– terminals. To maintain a generic battery model with physical-domain connectivity, a more robust approach is to use Subsystem Reference or a library block instead of Model Reference. These options preserve Simscape physical ports at the top level, allowing direct connection to charger/discharger models without introducing signal conversion.

If modularity and reuse are priorities, you can encapsulate the battery core in a masked subsystem and manage parameters through a Simulink data dictionary or configuration sets. For scenarios requiring multiple charger/discharger variants, a Variant Subsystem can be used alongside the battery subsystem to keep the architecture flexible. If you must integrate with Model Reference for workflow reasons, an interface wrapper using Simulink-PS Converter and PS-Simulink Converter blocks can bridge the gap, but this changes the interaction from physical to signal-based, which may not be ideal for fidelity.

[T.K]

Thank you for your response.

Based on your advice, I was able to create the battery model as a Subsystem model (.slx) and utilize it as a generic model by leveraging the Subsystem Reference block. Furthermore, I confirmed that even with a Subsystem model (.slx), variables can be assigned using a data dictionary and mask workspace, which fulfilled my requirements.

(A minor challenge I encountered was that while I defined a variable for the sampling interval within the mask workspace, it cannot be directly used with configuration parameters. Therefore, synchronizing the in-model and simulation sampling intervals will require some ingenuity.)

Your advice was highly helpful; thank you very much.