最新のリリースでは、このページがまだ翻訳されていません。 このページの最新版は英語でご覧になれます。

S-Function ターゲットを使用したシミュレーションの高速化、コードの再利用または知的所有権の保護

S-Function は、コード ジェネレーターがコードを生成できるシステム ターゲット ファイルの重要なクラスです。サブシステムを S-Function 内にカプセル化することにより、実行効率を高め、コードの再利用を容易にできます。

以下の節では S-Function ターゲットのプロパティについて説明し、その生成方法を示します。S-Function の構造の詳細については、C/C++ S-Function の基礎 (Simulink)を参照してください。

S-Function ターゲットについて

S-Function ターゲットを使用して、S-Function コンポーネントをビルドし、それを別のモデル内の S-Function ブロックとして使用することができます。以下のセクションでは、S-Function ターゲットの配布の注意事項について説明します。

S-Function ターゲットによって使用される TLC 変数 CodeFormat の値を 'S-Function' に設定すると、Simulink® C MEX S-Function アプリケーション プログラミング インターフェイス (API) に対応するコードが生成されます。この形式の アプリケーションには以下のものが含まれます。

  • モデルをコンポーネントに変換。モデル m1 用の S-Function ブロックを生成できます。次に、生成された S-Function ブロックを他のモデル m2 に配置できます。m2 のコードの再生成には m1 のコードの再生成は必要ありません。

  • サブシステムをコンポーネントに変換。サブシステムを別のモデルに抽出し、そのモデルから S-Function ブロックを生成することにより、サブシステムから再利用可能なコンポーネントを作成できます。この例の手順については、サブシステムから S-Function ブロックを生成を参照してください。

  • シミュレーションの高速化。多くの場合、モデルから生成された S-Function は元のモデルよりも実行が効率的になります。

  • コードの再利用。1 つのモデルの複数のインスタンスを、インスタンスごとにコードを複製することなく、他のモデルに組み込むことができます。各インスタンスは自身のもつ固有のデータを維持し続けます。

生成された S-Function ブロックを他のモデルに配置し、そのモデルから他の S-Function を生成することができます。この方法は入れ子にされた S-Function のレベルで可能です。入れ子に関する制限については、S-Function の入れ子構造に関する制限を参照してください。

メモ

S-Function ターゲットを使用して、内部ロジックを検査や修正から保護しながら再利用のためにアプリケーション コンポーネントを配布できますが、配布されるコンポーネントの知的財産を保護するための推奨ソリューションには次のものがあります。

  • 保護モデルは、ブロックとコード行の情報を隠した参照モデルです。詳細は、サードパーティからの保護モデルの参照 (Simulink)を参照してください。

  • Simulink 外部のシステム シミュレーションに使用するモデルまたはサブシステム用の共有ライブラリを生成するのに使用される、共有ライブラリ システム ターゲット ファイル。詳細については、Package Generated Code as Shared Libraries (Embedded Coder)を参照してください。

S-Function の配布に必要なファイル

シミュレーションとコード生成用に生成された S-Function ブロックを配布するには、さまざまなファイルが必要です。

生成された S-Function ブロックを配布して "シミュレーション用" の他のモデルにインクルードするには、その S-Function ブロックが生成された時点で作業フォルダーに生成されたバイナリ MEX ファイル オブジェクトだけを提供する必要があります。必要なファイルは以下のとおりです。

  • subsys_sf.mexext

ここで、subsys はサブシステム名で、mexext はプラットフォームに依存する MEX ファイルの拡張子です (mexextを参照)。例: SourceSubsys_sf.mexw64

生成された S-Function ブロックを配布して "コード生成用" に他のモデルにインクルードするには、その S-Function ブロックが生成された時点で作業フォルダーに生成されたすべてのファイルを提供します。必要なファイルは以下のとおりです。

  • subsys_sf.c または .cpp、ここで subsys はサブシステム名 (たとえば、SourceSubsys_sf.c)

  • subsys_sf.h

  • subsys_sf.mexext、ここで mexext はプラットフォームに依存する MEX ファイルの拡張子 (mexextを参照)

  • サブフォルダー subsys_sfcn_rtw とその内容

生成された S-Function コードは、関数がビルドされたホスト システムに一致する [コンフィギュレーション パラメーター][ハードウェア実行] パラメーター値を使用します。コード生成用のモデルで S-Function を使用する場合、モデルのこれらのパラメーター値が S-Function のパラメーター値と一致することを確認してください。

生成された S-Function でのサンプル時間の伝播

一定の基準が満たされている場合、生成された S-Function ブロックはそのモデルからそのサンプル時間を継承することができます。Model ブロックと生成された S-Function ブロックの間でのサンプル時間の伝播を制御する条件は、参照モデルのサンプル時間 (Simulink)と参照モデル用の継承サンプル時間に説明されています。

サンプル時間の継承の基準を満たす S-Function ブロックを生成するには、S-Function ブロックを生成するモデルのソルバーを制限しなければなりません。モデル コンフィギュレーション パラメーター [タイプ][固定ステップ] に、[周期的なサンプル時間の制約][サンプル時間に依存しない] に設定します。モデルがサンプル時間を継承できない場合、この設定はモデルのビルド時に Simulink ソフトウェアがエラー メッセージを出す原因になります。このオプションの詳細については、周期的なサンプル時間の制約 (Simulink)を参照してください。

ソルバー タイプの選択

以下の表に、最上位モデル ソルバー タイプで取りうる組み合わせを示します。これらのタイプは、生成された S-Function 用の離散サンプル時間または連続サンプル時間とソルバー タイプがモデルにあるかどうかに関連します。

最上位モデル ソルバー オプションとサンプル時間

 モデル コンフィギュレーション パラメーター: 最上位モデル コンフィギュレーション
サンプル時間ソルバー オプション、タイプ: 可変ステップソルバー オプション、タイプ: 固定ステップ
離散生成された S-Function には可変ステップ ソルバーが必要生成された S-Function は可変ステップ ソルバーまたは固定ステップ ソルバーをもつことが可能
連続生成された S-Function には可変ステップ ソルバーが必要生成された S-Function には固定ステップ ソルバーが必要

サブシステムから生成される S-Function には、ブロックにハードコードされるパラメーターがあります。Simulink では、シミュレーションの実行時ではなく、ブロックの生成時に、サンプル時間などのパラメーターが計算されます。生成された S-Function ブロックがデスティネーション モデルで予期したように機能するかどうかを確認することが重要です。

サブシステムから S-Function ブロックを生成

この節では、モデルからサブシステムを抽出し、それを使用して再利用可能な S-Function コンポーネントを生成する方法を説明します。

次の図に、信号をサブシステムに入力する簡単なモデル、SourceModel を示します。その次の図はサブシステム、SourceSubsys を示します。異なった幅とサンプル時間をもつ信号は、以下のもので構成されています。

  • サンプル時間が 1 の Step ブロック

  • サンプル時間が 0.5 の Sine Wave ブロック

  • 値がベクトル [-2 3] の Constant ブロック

    SourceModel

    SourceSubsys

目的はモデルから SourceSubsys を抽出し、それを元に S-Function ブロックを作成することで、S-Function ターゲットを使用します。S-Function ブロックはそれを作成する元になったサブシステムと同じ動作をしなければなりません。

このモデルでは、SourceSubsys は入力信号からサンプル時間と信号の幅を継承します。ただし、S-Function ターゲットを使用してモデルから生成された S-Function ブロックは、配線で接続されたすべての信号属性 (信号の幅やサンプル時間など) をもちます。(このルールに対する唯一の例外はサンプル時間に関するもので、生成された S-Function でのサンプル時間の伝播に説明されています)。

この例では、S-Function ブロックに、SourceModel に存在する SourceSubsys のプロパティをもたせることにします。このため、サブシステムを別の S-Function コンポーネントとして作成する前に、入力端子のサンプル時間と幅を明示的に設定しなければなりません。また、S-Function コンポーネントのソルバー パラメーターは元のモデルのパラメーターと同じでなければなりません。生成された S-Function コンポーネントは元のサブシステムと同様に動作します (詳細は、ソルバー タイプの選択を参照してください)。

S-Function コンポーネントとして SourceSubsys を作成するには、次のようにします。

  1. 新しいモデルを作成し、空のウィンドウに SourceSubsys ブロックをコピーして貼り付けます。

  2. SourceSubsys 内で、入力端子の信号の幅とサンプル時間が元のモデルの信号のものと一致するように設定します。Inport 1 の Filter の幅は 1 でサンプル時間は 1、Inport 2 の Xferfcn の幅は 1 でサンプル時間は 0.5 です。Inport 3 の offsets の幅は 2 でサンプル時間は 0.5 です。

  3. 生成される S-Function ブロックには 3 つの入力端子と 1 つの出力端子があります。次の図に示すように、入力端子と出力端子を SourceSubsys に接続します。

    これらの端子に信号の幅とサンプル時間が伝播されます。

  4. ソルバーのタイプ、モード、他のソルバー パラメーターをソース モデルと同じ値に設定します。モデル エクスプローラーを使用すると、この設定は簡単にできます。

  5. モデル コンフィギュレーション パラメーター [System target parameter][rtwsfcn.tlc] に設定します。

  6. [S-Function ターゲット] ペインを選択します。次の図に示したように、[新規モデルの作成] が選択されていることを確認します。

    このオプションを選択すると、ビルド プロセスは S-Function コンポーネントの作成後に新しいモデルを作成します。この新しいモデルには S-Function ブロックが含まれ、S-Function コンポーネントにリンクされます。

    [適用] をクリックします。

  7. サブシステムを含む新しいモデルを、SourceSubsys のように保存します。

  8. モデルを作成します。

  9. ビルド プロセスは作業フォルダー内に S-Function コンポーネントを作成します。作成の後、新しいモデル ウィンドウが表示されます。

    生成されたモデルを、オプションで SourceSubsys_Sfunction のように保存することができます。

  10. これでこの新しいモデルから生成された S-Function ブロックをコピーし、それを他のモデルやライブラリに使用することができます。

    メモ

    シミュレーション用やコード生成用に S-Function ブロックを配布するのに必要なファイルのリストは、S-Function の配布に必要なファイルを参照してください。

    次の図は元のモデルに接続された S-Function ブロックを示します。同じ入力信号を与えれば、この S-Function ブロックは元のサブシステムと同じように動作します。

    SourceModel のように設定され生成された S-Function

S-Function ブロックの実行速度は一般に、元のモデルよりも速くなります。この速度の差はモデルが大規模で複雑になるほど顕著になります。生成された S-Function を使用することにより、モデル化プロセスの効率を高めることができます。

生成された S-Function での調整可能なパラメーター

2 つの方法で、生成された S-Function で調整可能なパラメーターを使用することができます。

ソース モデルで [自動] ストレージ クラスを使用して調整可能と宣言したブロック パラメーターは、生成された S-Function で調整可能なパラメーターになります。これらのパラメーターは他のシステム ターゲット ファイルから生成されたコードの場合とは違い、生成された model_P (正式には rtP) パラメーター データ構造体の一部にはなりません。代わりに、mxGetPrmxGetData のような MEX API 呼び出しを使用して、生成されたコードはこれらのパラメーターにアクセスします。ユーザーのコードも同じ方法でこれらのパラメーターにアクセスしなければなりません。

MEX API の呼び出しの詳細は、About C MEX S-Functions (Simulink)およびアプリケーションで使用する MATLAB API の選択 (MATLAB)を参照してください。

S-Function ターゲットを使用して作成された S-Function ブロックは自動的にマスクされます。マスクは編集フィールドで調整可能なパラメーターごとに表示されます。既定の設定では、次の例のように、編集フィールドはパラメーターを変数名で表示します。

モデル コンフィギュレーション パラメーター [調整可能なパラメーターの値を使用] を選択することで、変数名ではなくパラメーターの値を表示するよう選択できます。

このパラメーターを選択すると、次の例のように、編集フィールドに (コード生成時の) 変数の値が表示されます。

システム ターゲット ファイル

S-Function ターゲットで使用するために、rtwsfcn.tlc システム ターゲット ファイルが提供されています。

チェックサムと S-Function ターゲット

コード ジェネレーターはモデル用のチェックサムを作成し、そのビルド プロセスで、コードの再利用機能、モデル参照機能およびエクスターナル モード機能用にチェックサムを使用します。

コード ジェネレーターは次の方法でモデルのチェックサムを計算します。

  1. モデルでサブシステムごとにチェックサムを計算します。サブシステムのチェックサムは、サブシステムのブロックのプロパティ (データ型、実数/複素数、サンプル時間、端子の次元など) の組み合わせになります。

  2. サブシステムのチェックサムと他のモデル レベルの情報を組み合わせます。

S-Function は関数 ssSetChecksumVal を呼び出してチェックサムに付加情報を追加することができます。この付加情報はブロック プロパティ解析中に取得されません。S-Function ターゲットの場合、チェックサムに追加される値は S-Function を生成する元のモデルまたはサブシステムのチェックサムです。

コード ジェネレーターはサブシステムとモデルのチェックサムを以下の用途に使用します。

  • コードの再利用 — モデル内の 2 つのサブシステムのチェックサムが同じ場合、コード ジェネレーターは 1 つの関数用だけのコードを生成します。

  • モデル参照 — 現在のモデルのチェックサムがモデル作成時のチェックサムと同じ場合、ビルド プロセスは参照モデルをリビルドしません。

  • エクスターナル モード — 現在のモデルのチェックサムがターゲット ハードウェアで実行中のコードのチェックサムと一致しない場合、ビルド プロセスでエラーが発生します。

生成された S-Function の互換性

モデルから MEX S-Function をビルドすると、コード ジェネレーターはレベル 2 のインラインでない S-Function をビルドします。生成コードとバイナリ MEX ファイル (*.mexw64 など) のリリースをまたがる使用には、次のような制限があります。

  • 以前の MATLAB リリース ソフトウェアからの S-Function ターゲット生成コードは、新しいリリースと互換性がありません。以前のリリースの生成コードを新しい MATLAB リリース ソフトウェアで再コンパイルしないでください。同じ MATLAB リリース ソフトウェアを使用して S-Function ターゲットのコードを生成し、そのコードを MEX ファイルにコンパイルしてください。

  • 以前の MATLAB リリース ソフトウェアから生成されたバイナリ S-Function MEX ファイルは、手書きの S-Function と同じ互換性注意事項の下で同じリリースまたはより新しいリリースと共に使用できます。詳細については、S-Function Compatibility (Simulink)を参照してください。

  • コード ジェネレーターは、生成された S-Function を含むモデルからコードを生成したり実行可能ファイルをビルドしたりできます。このサポートについては、モデルをビルドしたのと同じ MATLAB リリース ソフトウェアで S-Function をビルドする必要があります。以前の MATLAB リリース ソフトウェアで生成された S-Function MEX ファイルをモデルに組み込み、より新しいリリースでモデルをビルドすることはできません。

S-Function ターゲットの制限

式での調整可能な変数の使用に関する制限

式で調整可能な変数を使用する場合、一定の制限があります。コード ジェネレーターでコードの生成中にサポートされない式が検出されると、警告が表示されて、等価の数値がコードに生成されます。制限の一覧については、調整可能な式の制限を参照してください。

パラメーターの調整

S-Function ブロックは、以下と共に使用する調整可能なパラメーターの調整をサポートしていません。

  • 複素数値

  • 定数に変換される値またはデータ型 (モデル コンフィギュレーション パラメーター [最適化][既定のパラメーター動作][インライン] に設定)。

  • 組み込まれていないデータ型

調整可能なパラメーターを選択する場合 ([Subsystem に対する S-function を生成] ダイアログ ボックスから)、以下のことが行われます。

  • ビルド プロセス中に警告を生成

  • 生成された S-Function ブロック マスクはこれらのパラメーターを表示しない

ランタイム パラメーターと S-Function の互換性診断

モデル コンフィギュレーション パラメーター [アップグレードの必要な S-function][警告] または [エラー] に設定すると、コード ジェネレーターは [S-Function を生成] 機能を使用して作成した S-Function に対するアップグレードを指示します。これは S-Function システム ターゲット ファイルがランタイム パラメーターを登録していないためです。ランタイム パラメーターはインライン化された S-Function だけでサポートされており、生成された S-Function はインライン化される (たとえば、他のインラインでない S-Function を呼び出したり含んだりすることができる) ことを回避する機能をサポートします。

パラメーター [アップグレードの必要な S-Function][なし] に設定することにより、この制限を回避することができます。

Goto ブロックと From ブロックの使用に関する制限

S-Function システム ターゲット ファイルを使用する場合、コード ジェネレーターは I/O の対象をルート モデルの Inport ブロックと Outport ブロック (または S-Function ターゲットを生成する元になった Subsystem ブロックの Inport ブロックと Outport ブロック) に制限します。コード ジェネレーターは、Goto ブロックまたは From ブロックのコードを生成しません。

この制限を回避するには、Goto ブロックと From ブロックを使用してルート モデルとサブシステムの間でデータを渡すのではなく、必要な Inport ブロックと Outport ブロックをもつモデルとサブシステムを作成します。そして、生成された S-Function を組み込んだモデルに、Goto ブロックと From ブロックを追加します。

制限を回避しない例

  • From ブロックとサブシステムをもつルート モデル、Subsystem1

  • グローバル可視性をもち、入力をルート モデルの From ブロックに渡す Goto ブロックをもつ Subsystem1

  • S-Function ターゲットで生成された S-Function で置き換えられる Subsystem1 — 生成された S-Function は Goto ブロックを実装していないため、モデルを実行すると警告が出る

制限を回避した例

Subsystem1GoTo ブロックを Outport ブロックで置き換えます。生成された S-Function をルート モデルに接続すると、その出力は To Workspace ブロックに直接接続されます。

S-Function の作成と更新に関する制限

S-Function システム ターゲット ファイルを使用する S-Function の作成と更新については、次の制限があります。

  • S-Function システム ターゲット ファイルを使用する Model ブロックを含むモデルを作成することはできません。これは、サブシステムに Model ブロックが含まれている場合、コンテキスト メニューの右クリックを使用してサブシステムを作成できないという意味でもあります。これは S-Function ターゲットを使用して生成された S-Function だけの制限で、ERT S-Function では制限はありません。

  • S-Function ブロックを生成したモデルを変更する場合、ビルド プロセスは生成された S-Function ブロックを含むモデルを自動的にリビルドしません。これは Model ブロックで参照されたモデルが (モデル参照の [リビルド] コンフィギュレーション設定により) 変更される場合に自動的にリビルドされることとは対照的です。

  • 対応する TLC ファイルのない手書きの S-Function は例外のないコードを含まなければなりません。例外のないコードの詳細については、Exception Free Code (Simulink)を参照してください。

サポートされていないブロック

S-Function 形式は以下の組み込みブロックをサポートしません。

  • Interpreted MATLAB Function ブロック

  • 次のいずれかを含む S-Function ブロック

    • MATLAB® 言語 S-Function (C コード生成用の TLC ファイルがない場合)

    • Fortran S-Function (C コード生成用の TLC ファイルがない場合)

    • MATLAB 環境を呼び出す C/C++ MEX S-Function

  • Scope ブロック

  • To Workspace ブロック

S-Function 形式は、embeddedtargetslib ブロック ライブラリからのブロックをサポートしません。

コード生成でサポートされない SimState

C-MEX とレベル 2 の MATLAB 言語 S-Function 内で SimState を使用し、シミュレーション状態を保存し復旧することができます。S-Function Compliance with the ModelOperatingPoint (Simulink)を参照してください。ただし、SimState は S-Function システム ターゲット ファイルを含むコード生成はサポートしません。

サポートされない TLC フック関数によるコード パフォーマンスのプロファイリング

コードの実行速度のプロファイリングに説明されている Target Language Compiler (TLC) フック関数インターフェイスを使用した、生成されたコードのパフォーマンスのプロファイリングは S-Function ターゲットではサポートされません。

メモ

Embedded Coder® のライセンスがある場合、ソフトウェアインザループ (SIL) およびプロセッサインザループ (PIL) のシミュレーションに基づくよりシンプルな代替アプローチについては、コード実行のプロファイル (Embedded Coder)を参照してください。

S-Function の入れ子構造に関する制限

生成された S-Function ブロックをモデルやサブシステム内で入れ子構造にして、それから他の S-Function を生成する場合には次の制限があります。

  • ソフトウェアは入れ子構造の S-Function について非バーチャルなバスの入力信号と出力信号をサポートしません。

  • S-Function と同じ名前をもつモデルやサブシステム内で (数レベル離れている場合もあります) S-Function を入れ子にするのは避けてください。このような状況では、S-Function は再帰的に呼び出される可能性があります。ソフトウェアは現状ではこのような S-Function のループを検出しないため、MATLAB セッションの中止やハングアップにつながる結果になります。このような事態を防ぐには、MATLAB のパス上の既存の MEX ファイル名を複製しないようにするために、S-Function ターゲットとして生成される予定のサブシステムやモデルに一意な名前を付けます。

ユーザー定義のデータ型に関する制限

S-Function システム ターゲット ファイルは、Simulink.AliasTypeSimulink.Bus および Simulink.NumericType オブジェクトに基づくものも含む、ユーザー定義のデータ型で指定される HeaderFile プロパティをサポートしません。モデルでユーザー定義されたデータ型が HeaderFile プロパティを使用して関連するヘッダー ファイルを指定する場合、S-Function システム ターゲット ファイルを使用するコード生成はその値を無視し、対応するインクルード文を生成しません。

S-Function ターゲットの右クリックによる生成の制限

Function-Call Subsystem ブロックを右クリックして S-Function ターゲットを生成すると、元のサブシステムと生成された S-Function の間の整合性を確保できないことがあります。不整合が発生するのは、Function-Call Subsystem ブロック内の Trigger Port ブロックの [イネーブル時の状態] パラメーターが [継承] に設定されている場合です。[イネーブル時の状態] パラメーターは、[リセット] または [保持] に設定しなければなりません。それ以外の設定では Simulink でエラーが発生します。

バス I/O 信号を使用した S-Function の制限

S-Function ターゲットを使用して生成された S-Function にバス入力信号またはバス出力信号がある場合には、生成されたバス データ構造体にはバス要素に関するフィールドと、シミュレーション中に使用される Simulink の表現を整合させるためのパディングが含まれている可能性があります。ただし、モデルに S-Function を挿入して、grt.tlc のようなモデル ターゲットを使用するコードを生成する場合、モデル ビルドのために生成されたバス構造体の配置が S-Function に対して生成されたパディングと一致せずに、コード実行の数値結果に影響を与える場合があります。モデル シミュレーションとモデル コードの実行の間で構造体の配置を整合させるには、それぞれの Simulink.Bus オブジェクトに対して、HeaderFile プロパティを変更して、パディングされていないバス構造体ヘッダー ファイルを削除します。その結果、S-Function のために生成されたバスの typedef がモデルのコードで再利用されます。

関数呼び出しの I/O 信号を使用したサブシステムの制限

S-Function ターゲットでは、関数呼び出しのトリガー入力または関数呼び出し出力をもつサブシステムからの S-Function ブロックの作成をサポートしません。

データ ストアへのアクセス

モデル内の S-Function がシミュレーション中にデータ ストアにアクセスする場合、Simulink はデータ ストアの診断を無効にします。

  • モデルから S-Function を作成した場合、診断はグローバルなデータ ストアに対しても無効となります。

  • サブシステムから S-Function を作成した場合、診断は次のデータ ストアに対して無効となります。

    • グローバルなデータ ストア

    • サブシステムの外部に配置され、Data Store Read ブロックまたは Data Store Write ブロックによってアクセスされるデータ ストア

サブシステム マスクから Inport または Outport ブロックのパラメーターを指定できない

S-Function ブロックをサブシステムから生成する場合、Inport または Outport ブロックのパラメーターをサブシステム マスク変数を使用して指定することはできません。S-Function ブロックを使用するシミュレーションを実行しようとすると、たとえば次のようなエラーが生成されます。

Invalid setting in 'testSystem/Subsystem/__OutputSSForSFun__/Out2' 
for parameter 'PortDimensions'
...

関連するトピック