SIL シミュレーションおよび PIL シミュレーション

SIL シミュレーションおよび PIL シミュレーションとは

Embedded Coder^® を使用して、モデルのソフトウェアインザループ (SIL) シミュレーションおよびプロセッサインザループ (PIL) シミュレーションを実行できます。これらのシミュレーションでは、最上位モデルまたはモデルの一部のソースコードを生成します。SIL シミュレーションでは、生成されたコードを開発用コンピューターでコンパイルおよび実行します。PIL シミュレーションでは、開発用コンピューターでソースコードをクロスコンパイルし、ターゲットプロセッサまたは同等の命令セットシミュレーターでオブジェクトコードをダウンロードして実行します。

SIL シミュレーションおよび PIL シミュレーションでは、以下を実行できます。

モデルおよび生成されたコードが数値的に等価であるかどうかをテストする。
コードカバレッジを確認する。
コード実行プロファイリングを実行する。

SIL および PIL を使用する理由

SIL および PIL により、テストを早期に実行し、欠陥を修正できます。たとえば、ノーマルモードでシステムコンポーネントをモデル化し、テストできます。その後、コンパイルされた生成コードを実行する SIL シミュレーションまたは PIL シミュレーションでテストスイートを再利用できます。数値的な等価性をチェックするには、ノーマルシミュレーションと SIL シミュレーションまたは PIL シミュレーションの結果を比較します。Simulink^® 環境に個別のインフラストラクチャでの生成コードのテストを任せる必要はありません。

以下の表に、SIL および PIL を使用できる状況を説明します。

状況	使用
生成 (またはレガシ) コードの数値出力を検証するノーマルモードのシミュレーション用に開発されたテストベクトルを再利用して、モデルと生成コード間の数値的等価性をテストします。SIL/PIL Manager Verification WorkflowおよびTest Two Simulations for Equivalence (Simulink Test)を参照してください。	SIL および PIL
生成コードのメトリクスを収集します。コードカバレッジ。コードカバレッジを参照してください。実行プロファイリング。Create Execution-Time Profile for Generated Codeを参照	SIL および PIL
(IEC Certification Kit のライセンスが必要) 生成された C/C++ コードについて、ISO 26262-6、IEC 61508-3、IEC 62304、EN 50128、および EN 50657 機能安全規格で定義されたソフトウェア安全ライフサイクル全体の要件に従って、検証と妥当性確認のアクティビティを実行します。IEC Certification Kit モデルベースデザインワークフローにおける SIL および PIL の検証アクティビティの詳細については、Artifacts Explorer の Reference Workflow for Embedded C/C++ Applications (`certkitiec_ecoder_workflow.docx/pdf`) アーティファクトを参照してください。	SIL および PIL
(DO Qualification Kit のライセンスが必要) DO-178C および DO-333 安全規格の関連目標を満たすために統合プロセスの出力をテストします。詳細については、Testing of Outputs of Integration Process (DO Qualification Kit) を参照してください。この情報は、Artifacts Explorer の Model-Based Design Workflow for DO-178C (`qualkitdo_do178_workflow.pdf`) アーティファクトでも確認できます。	SIL および PIL
ターゲットハードウェアがない場合、PIL の便利な代替手段になります。	SIL
ターゲットハードウェアがある場合、評価ボードまたは命令セットシミュレーターなどで以下を実行します。ターゲット固有コード (コード置換の最適化など) およびレガシコードの動作を確認する。コード置換とはおよびWhat Is Code Replacement Customization?を参照してください。コードの実行速度とメモリフットプリントを最適化する。この表内の、実行プロファイリングメトリクスとスタックプロファイリングメトリクスに関する情報を参照してください。コンパイラ設定や最適化の影響 (ANSI^® C オーバーフロー動作からの乖離など) を調査する。ノーマルシミュレーション手法では、限られたメモリリソースやターゲット固有に最適化されたコードの動作など、ハードウェアによって課される制限および要件が考慮されません。特定のターゲットでの PIL シミュレーションの実行の詳細については、カスタムターゲットのサンプルを参照してください。	PIL

メモ

SIL シミュレーションモードおよび PIL シミュレーションモードは、モデルのシミュレーション時間を短縮するように設計されていません。モデルのシミュレーションを高速化する場合は、ラピッドアクセラレータモードを使用します。詳細については、アクセラレーションとはを参照してください。

SIL シミュレーションおよび PIL シミュレーションの仕組み

SIL シミュレーションまたは PIL シミュレーションでは、最上位モデルまたはモデルの一部についてコードが生成されます。SIL では、このコードは開発用コンピューター用にコンパイルされ、実行されます。PIL では、コードがターゲットハードウェア用にクロスコンパイルされ、ターゲットプロセッサで実行されます。

通信チャネルを通じて、Simulink は、シミュレーションのサンプル間隔ごとにスティミュラス信号をコンピューターまたはターゲットプロセッサのコードに送信します。

最上位モデルの場合、Simulink はベースワークスペースまたはモデルワークスペースからのスティミュラス信号を使用します。
SIL モードまたは PIL モードでシミュレーションするモデルの一部のみを指定した場合、モデルの一部は Simulink 内に残り、モデルのこの部分についてコードは生成されません。通常、モデルのこの部分は、ハードウェアで実行されているソフトウェア向けにテストベクトルを提供するよう構成します。モデルのこの部分は、アルゴリズムの他の部分またはアルゴリズムが動作する環境を表すことができます。

コンピューターまたはターゲットプロセッサが Simulink から信号を受信すると、プロセッサで 1 つのサンプルステップに対して SIL アルゴリズムまたは PIL アルゴリズムが実行されます。SIL アルゴリズムまたは PIL アルゴリズムは、このステップ中に計算された出力信号を、通信チャネルを通じて Simulink に返します。シミュレーションの 1 サンプルサイクルが完了すると、Simulink は次のサンプル間隔に進みます。プロセスは繰り返し実行され、シミュレーションが進行します。SIL シミュレーションおよび PIL シミュレーションはリアルタイムで実行されません。各サンプル期間に、Simulink およびオブジェクトコードが I/O データを交換します。

SIL シミュレーションと PIL シミュレーションの比較

SIL シミュレーションまたは PIL シミュレーションのタイプ	SIL シミュレーションの動作	PIL シミュレーションの動作
次で指定: 最上位モデルのシミュレーションモード Model ブロックの [シミュレーションモード] パラメーター	開発用コンピューターで生成されたソースコードの動作をテストする。コードは開発用コンピューター (ターゲットとは異なるコンパイラおよび異なるプロセッサアーキテクチャ) 向けにコンパイルされるため、シミュレーションではターゲットハードウェア用にコンパイルされたコードはテストされません。生成された量産コードは、MATLAB^® プロセスに関係なく、個別のプロセスとして開発用コンピューターでコンパイルおよび実行される。実行はホスト/ホストおよび非リアルタイムで行われる。	製品に展開する予定のオブジェクトコードを実際のターゲットハードウェアまたは命令セットシミュレーターのいずれかでテストする。開発用コンピューターで、生成された量産コードがターゲット用にクロスコンパイルされる。オブジェクトコードはターゲットプロセッサまたは命令セットシミュレーターにダウンロードされて実行されます。実行はホスト/ターゲットおよび非リアルタイムで行われる。
サブシステムから作成された SIL ブロックまたは PIL ブロックを使用する。	シミュレーションでは、コンパイルされたオブジェクトコードが S-Function を通じて実行される。S-Function は、開発用コンピューターでスタンドアロンアプリケーションとして実行されているオブジェクトコードと通信します。SIL ブロックの実行は、MATLAB プロセスに依存しません。実行はホスト/ホストおよび非リアルタイムで行われる。	シミュレーションでは、クロスコンパイルされたオブジェクトコードが開発用コンピューターで S-Function を通じて実行さる。S-Function は、ターゲットプロセッサまたは命令セットシミュレーターでスタンドアロンアプリケーションとして実行されているオブジェクトコードと通信します。実行はホスト/ターゲットおよび非リアルタイムで行われる。

SIL および PIL のコードインターフェイス

最上位モデルなど、実行するときにスタンドアロンコードを作成するか、単一の展開可能なコンポーネントのサブシステムのビルドを右クリックします。スタンドアロンコードをコンパイルして、スタンドアロンの実行可能ファイルにリンクすることも、他のコードと統合することもできます。スタンドアロンコードのインターフェイスの詳細については、生成された C 関数インターフェイスをモデルのエントリポイント関数用に構成を参照してください。

参照モデルの階層構造のコードを生成すると、最上位モデルのスタンドアロン実行可能ファイルと、各参照モデルの "モデル参照ターゲット" と呼ばれるライブラリモジュールが生成されます。コードが実行されると、スタンドアロンの実行可能ファイルは適用可能なモデル参照ターゲットを呼び出し、参照モデルの出力を計算します。詳細については、モデル参照ターゲットのビルドを参照してください。

生成されたコードをレガシコードと統合するには、スタンドアロンコードインターフェイスがドキュメント化されるため、スタンドアロンコードを使用します。

メモ

SIL シミュレーションおよび PIL シミュレーションでは、カスタムコードインターフェイスは直接サポートされません。レガシコードツール、S-Function Builder、手書きのコードなどを使用してこれらのインターフェイスを Simulink に S-Function として組み込むことができます。その後、SIL シミュレーションおよび PIL シミュレーションを使用してカスタムコードを検証できます。

次の表に、SIL シミュレーションおよび PIL シミュレーションで生成されるインターフェイスを示します。

SIL/PIL シミュレーションコードインターフェイス

最上位モデル

SIL/PIL シミュレーション	コードインターフェイス
最上位モデル	SIL/PIL シミュレーションでは、スタンドアロンのコードインターフェイスが生成されます。コードが存在する場合、モデルのスタンドアロンコードが呼び出されます。コードが存在しない場合、スタンドアロンコードが生成されます。
Model ブロック	[コードインターフェイス] ブロックパラメーターを `[最上位モデル]` に設定すると、SIL/PIL シミュレーションでは、スタンドアロンのコードインターフェイスが生成されます。モデルのスタンドアロンコードが存在する場合は、そのコードが呼び出されます。存在しない場合は、`slbuild('model')` コマンドを使用してスタンドアロンコードが生成されます。 [コードインターフェイス] ブロックパラメーターを `[モデル参照]` に設定すると、SIL/PIL シミュレーションでは、モデル参照コードインターフェイスが生成されます。Model ブロックのモデル参照ターゲットが存在する場合は、そのターゲットが呼び出されます。存在しない場合は、`slbuild('model', 'ModelReferenceCoderTarget')` コマンドを使用してモデル参照ターゲットが生成されます。
SIL ブロックまたは PIL ブロック	ブロックは、スタンドアロンのコードインターフェイスを使用します。

SIL/PIL シミュレーションでは、スタンドアロンのコードインターフェイスが生成されます。コードが存在する場合、モデルのスタンドアロンコードが呼び出されます。コードが存在しない場合、スタンドアロンコードが生成されます。

Model ブロック

[コードインターフェイス] ブロックパラメーターを [最上位モデル] に設定すると、SIL/PIL シミュレーションでは、スタンドアロンのコードインターフェイスが生成されます。モデルのスタンドアロンコードが存在する場合は、そのコードが呼び出されます。存在しない場合は、slbuild('model') コマンドを使用してスタンドアロンコードが生成されます。

[コードインターフェイス] ブロックパラメーターを [モデル参照] に設定すると、SIL/PIL シミュレーションでは、モデル参照コードインターフェイスが生成されます。Model ブロックのモデル参照ターゲットが存在する場合は、そのターゲットが呼び出されます。存在しない場合は、slbuild('model', 'ModelReferenceCoderTarget') コマンドを使用してモデル参照ターゲットが生成されます。

SIL ブロックまたは PIL ブロックブロックは、スタンドアロンのコードインターフェイスを使用します。

スケジューリングに関する考慮事項

項目情報

代数ループ

項目	情報
代数ループ	SIL シミュレーションおよび PIL シミュレーションで発生するが、ノーマルモードのシミュレーションでは発生しない代数ループがあります。コード生成の最適化の [1 つの出力/更新関数] では、出力と更新関数の組み合わせにより直達が導入されるため、代数ループが導入される可能性があります。 [1 つの出力/更新関数] は [代数ループの発生の最小化] ([Subsystem パラメーター] ダイアログボックスおよび [コンフィギュレーションパラメーター] 、 [モデル参照] ペイン内) と互換性がありません。[代数ループの発生の最小化] を使用すると、コード生成では生成コードを出力と更新関数との間で分割して直達を回避することで、代数ループを除去できます。バーチャルサブシステムのコードを生成すると、コード生成ではサブシステムが Atomic として扱われ、それに従ってコードが生成されます。結果のコードによって、代数ループの適用などでモデルの実行動作が変化し、シミュレーションの動作が不整合になる可能性があります。モデルのシミュレーションと実行動作の整合性を確保するためには、バーチャルシステムを Atomic サブシステムとして宣言します。詳細については、以下を参照してください。代数ループの概念代数ループ Simulink モデリングコンポーネント
フィードバックループのエクスポートされた関数	モデルに Function-Call Subsystem があり、コンテキストに依存する入力 (フィードバック信号など) のあるサブシステムをエクスポートすると、生成されたコードでの SIL/PIL シミュレーションの結果とモデルのノーマルモードシミュレーションの結果が異なる場合があります。SIL/PIL シミュレーションとノーマルモードのシミュレーションの結果を同一にするための 1 つの方法は、モデルでFunction-Call Feedback Latchブロックを使用することです。コンテキストに依存する入力をコンテキストに依存しない入力にすることができます。 [コンテキスト依存の入力] コンフィギュレーションパラメーターを `[警告]` に設定すると、Embedded Coder では、エクスポートされた Function-Call Subsystem のコンテキスト依存入力を識別する警告が生成されます。詳細については、以下を参照してください。 Simulink モデリングコンポーネント Function-Call Feedback Latch コンテキスト依存の入力

SIL シミュレーションおよび PIL シミュレーションで発生するが、ノーマルモードのシミュレーションでは発生しない代数ループがあります。

コード生成の最適化の [1 つの出力/更新関数] では、出力と更新関数の組み合わせにより直達が導入されるため、代数ループが導入される可能性があります。
[1 つの出力/更新関数] は [代数ループの発生の最小化] ([Subsystem パラメーター] ダイアログボックスおよび [コンフィギュレーションパラメーター] 、 [モデル参照] ペイン内) と互換性がありません。[代数ループの発生の最小化] を使用すると、コード生成では生成コードを出力と更新関数との間で分割して直達を回避することで、代数ループを除去できます。
バーチャルサブシステムのコードを生成すると、コード生成ではサブシステムが Atomic として扱われ、それに従ってコードが生成されます。結果のコードによって、代数ループの適用などでモデルの実行動作が変化し、シミュレーションの動作が不整合になる可能性があります。
モデルのシミュレーションと実行動作の整合性を確保するためには、バーチャルシステムを Atomic サブシステムとして宣言します。

詳細については、以下を参照してください。

フィードバックループのエクスポートされた関数

モデルに Function-Call Subsystem があり、コンテキストに依存する入力 (フィードバック信号など) のあるサブシステムをエクスポートすると、生成されたコードでの SIL/PIL シミュレーションの結果とモデルのノーマルモードシミュレーションの結果が異なる場合があります。SIL/PIL シミュレーションとノーマルモードのシミュレーションの結果を同一にするための 1 つの方法は、モデルでFunction-Call Feedback Latchブロックを使用することです。コンテキストに依存する入力をコンテキストに依存しない入力にすることができます。

[コンテキスト依存の入力] コンフィギュレーションパラメーターを [警告] に設定すると、Embedded Coder では、エクスポートされた Function-Call Subsystem のコンテキスト依存入力を識別する警告が生成されます。

詳細については、以下を参照してください。

インポートデータと追加の生成コード

SIL または PIL シミュレーションでは、モデルから生成されたコードは変更されません。インポートデータを使用する場合、SIL または PIL シミュレーションによって、SIL または PIL ターゲットアプリケーションのコンパイルとリンクをサポートする必要がある追加のコードが生成されます。追加の生成コードはモデルで指定したインターフェイスに対応します。

このセクションでは、以下について説明します。

インポートデータで、SIL または PIL シミュレーションでストレージが定義される場合と、ストレージを定義する必要がある場合。
SIL または PIL シミュレーションで追加のコードが生成されるインターフェイス

SIL または PIL シミュレーションのインポートデータ

SIL シミュレーションおよび PIL シミュレーションでは、インポートデータ定義をもつストレージクラスを指定する信号、パラメーターおよびデータストアを使用できます。シミュレーションでは、以下に関連付けられたインポートデータのストレージが定義されます。

コンポーネントのルートレベルにある信号 (I/O 境界上)。
ベースワークスペースまたはデータディクショナリのパラメーター。モデルワークスペースのパラメーターの場合は、次のようになります。
- 最上位モデルの SIL/PIL および SIL/PIL ブロックシミュレーションではストレージが定義される。
- Model ブロックの SIL/PIL シミュレーションではストレージが定義されない。ストレージを定義し、MATLAB の値と一致する初期値を指定しなければなりません。
グローバルなデータストア。

SIL シミュレーションおよび PIL シミュレーションでは、他のインポートデータのストレージは定義されません。たとえば、シミュレーションでは、次の関連付けられたインポートデータのストレージは定義されません。

内部信号 (I/O 境界上にない)。内部信号のデータがポインターの使用によってインポートされた構造体内にある場合、シミュレーションでストレージが定義されることに注意してください。
ローカルデータストア。

これらの場合は、テスト対象のコンポーネントによって含まれるカスタムコードまたは PIL rtw.pil.RtIOStreamApplicationFramework API を通じてストレージを定義します。

Tunable Parameters and SIL/PILも参照してください。

追加の生成コードを生成するインターフェイス

次の表では、SIL または PIL シミュレーションでインターフェイスの追加コードが生成されるシナリオについて説明します。

シナリオ詳細

シナリオ	詳細
`GetSet` カスタムストレージクラス	SIL シミュレーションおよび PIL シミュレーションは、`GetSet` カスタムストレージクラスをサポートします。SIL/PIL テストハーネスでは、シミュレーション中に使用される関数 `Get` と `Set` の C 定義が提供されます。詳細については、Access Data Through Functions with Storage Class GetSetを参照してください。
タイプ `Other` のカスタムストレージクラス	[タイプ] が `Other` に設定されているカスタムストレージクラスで SIL および PIL のサポートを有効にするには、カスタムストレージクラスのカスタム属性クラスを作成し、`true` に設定された Boolean プロパティ `SupportSILPIL` にカスタム属性クラスを関連付けます。 classdef CSCOtherAttributes < Simulink.CustomStorageClassAttributes properties(PropertyType = 'logical scalar') SupportSILPIL = true; end end カスタム属性の詳細については、Further Customize Generated Code by Writing TLC Codeおよびストレージクラスの TLC コードの記述によるデータ表現の詳細な制御を参照してください。 SIL または PIL アプリケーションインターフェイスを作成するために、コードジェネレーターは、関連付けられたカスタム TLC ファイルで関数 `DataAccess` と `ClassAccess` を呼び出し、必要な情報を取得します。コードジェネレーターは、ビルドフォルダーのビルドアーティファクトに抽出された情報を格納します。グループ化されていないカスタムストレージクラスの場合は、次のようになります。コードジェネレーターは、`define`、`declare`、`layout`、`contents`、`address`、または `set` の値を取る request 引数を指定して `DataAccess` を呼び出します。コードジェネレーターは、次のいずれに該当する場合、`DataAccess(record, "define", "", "")` で返される文字列を使用して SIL アプリケーションまたは PIL アプリケーションで変数を定義します。信号またはパラメーターに `Imported` データスコープがある。モデルでモデル参照コードインターフェイスが使用されている。モデルで最上位モデルコードインターフェイスが使用され、`EnableDataOwnership` が `on` で、カスタムストレージクラスの `Owner` 属性が空でなく、現在のモデルの名前と等しくない。コードジェネレーターは、次に該当する場合、`DataAccess(record, "declare", "", "")` から返される文字列を使用して SIL または PIL アプリケーションで変数を定義します。モデルで最上位モデルコードインターフェイスが使用されている。信号またはパラメーターで `Exported` ストレージクラスが使用されている。 `EnableDataOwnership` が `off` であるか、`EnableDataOwnership` が `on` で、カスタムストレージクラスの `Owner` 属性が空またはモデル名と等しい。コードのパッケージ化が設定されているため、変数は `model.h` または `model.h` でインクルードされるヘッダーファイルで宣言されません。グループ化されているカスタムストレージクラスの場合は、次のようになります。コードジェネレーターは、`layout`、`address`、または `set` の値を取る `request` 引数を指定した `DataAccess` を呼び出します。コードジェネレーターは、`groupTypeDeclDefn` の値を取る `request` 引数を指定した `ClassAccess` を呼び出します。次のいずれかに該当する場合は、グループ化されたタイプ (`struct`) 定義とグループ化された変数の `extern` 宣言を指定しなければなりません。信号またはパラメーターに `Imported` データスコープがある。モデルでモデル参照コードインターフェイスが使用されている。モデルで最上位モデルコードインターフェイスが使用され、`EnableDataOwnership` が `on` で、カスタムストレージクラスの `Owner` 属性が空でなく、現在のモデルの名前と等しくない。カスタムストレージクラスに関連付けられたヘッダーファイルで、`HeaderFile` 属性、または `model.h` ファイルを通じてインクルードするカスタムコードを使用して、定義と宣言を指定します。SIL または PIL アプリケーションで変数を定義するために、コードジェネレーターは `ClassAccess(record, "groupTypeDeclDefn")` から返される文字列を使用します。静的初期化では、データスコープが `Exported` の場合に生成される順序とは異なる `struct` 要素の順序を前提とすることができます。コードジェネレーターは `ClassAccess(record, "groupTypeDeclDefn")` のクエリを実行するときに、カスタムストレージクラスのデータ初期化属性を値 `None` で一時的にオーバーライドします。 SIL アプリケーションまたは PIL アプリケーションがアドレスでコード内の変数にアクセスできるかどうかを判断するために、コードジェネレーターは `DataAccess(record, "layout", "", "")` から返される要素を使用します。開発用コンピューターとターゲットハードウェア間で入力ポートまたは出力ポート、調整可能なパラメーター、あるいはグローバルデータストアメモリ値を転送するアプリケーション内の機能を作成するために、コードジェネレーターは次からの出力を使用します。最初に返される要素が `scalar`、`vector`、`row-mat`、または `col-mat` の場合は `DataAccess(record, "address", idx, reim)`。最初に返される要素が `other` の場合は `DataAccess(record, "contents", idx, reim)` (または `DataAccess(record, "set", idx, reim)`)。コードジェネレーターは、`row-mat` および `col-mat` の場合、行列はそれぞれ行優先の形式で格納されると仮定します。この仮定は、モデルの残りの部分の配列レイアウトには依存しません。コードジェネレーターは、カスタムストレージクラスで実装されたストレージの配列レイアウトがモデルの残りの部分と異なる場合、カスタムストレージファイルに関連付けられている TLC ファイルによって必要な変換が実行されると仮定します。タイプが `Other` のカスタムストレージクラスと関連付けられているカスタム TLC ファイルを作成して、(要求されたコードフラグメントを返すのに加え) 他の関数を実行できます。たとえば、カスタムファイルに直接書き込むか、ベースワークスペースの状態を変更する MATLAB 関数を呼び出します。`DataAccess` または `ClassAccess` が呼び出されたときにこれらの関数を必ずしも実行するわけではない場合は、TLC 関数 `LibIsAccessingCustomDataForSILPIL(record)` を使用して、ターゲットコードの生成と、SIL アプリケーションまたは PIL アプリケーションの作成用のコードフラグメントの要求を区別します。次に例を示します。 ... %case "contents" %if !LibIsAccessingCustomDataForSILPIL(record) %matlab functionWithSideEffects() %endif %return LibDefaultCustomStorageContents(record, idx, reim) ... カスタムストレージクラスのその他の制限も参照してください。
AUTOSAR ランタイム環境	最上位モデルと Model ブロック SIL/PIL および SIL/PIL ブロックのシミュレーションを使用して、AUTOSAR ソフトウェアコンポーネントのモデルベースのテストを実行できます。ソフトウェアによって、AUTOSAR ソフトウェアコンポーネントの生成コードと基本のコンポーネント固有の AUTOSAR ランタイム環境 (RTE) がリンクされてテストアプリケーションが作成されます。このアプリケーションでは、AUTOSAR ソフトウェアコンポーネントによって実行された AUTOSAR API の呼び出しがテストされます。参照モデルを含む最上位の AUTOSAR ソフトウェアコンポーネントの場合は、最上位モデルまたは Model ブロック ([コードインターフェイス] が `[最上位モデル]` に設定されている) の SIL シミュレーションまたは PIL シミュレーションを実行できます。シミュレーションで、ソフトウェアにより次が行われます。参照モデルのコンパイル前に、AUTOSAR RTE ヘッダーファイルが生成される。参照モデルのコンパイル用の RTE インクルードパスが提供される。最上位の AUTOSAR SWC 内の参照モデルに対して Model ブロック ([コードインターフェイス] が `[モデル参照]` に設定されている) の SIL シミュレーションまたは PIL シミュレーションを実行することもできます。この場合は、シミュレーションを実行する前に、親コンポーネントを作成して RTF ヘッダーファイルを生成しなければなりません。親コンポーネントを作成しないと、SIL シミュレーションまたは PIL シミュレーションが失敗します。

GetSet カスタムストレージクラス

SIL シミュレーションおよび PIL シミュレーションは、GetSet カスタムストレージクラスをサポートします。SIL/PIL テストハーネスでは、シミュレーション中に使用される関数 Get と Set の C 定義が提供されます。詳細については、Access Data Through Functions with Storage Class GetSetを参照してください。

タイプ Other のカスタムストレージクラス

[タイプ] が Other に設定されているカスタムストレージクラスで SIL および PIL のサポートを有効にするには、カスタムストレージクラスのカスタム属性クラスを作成し、true に設定された Boolean プロパティ SupportSILPIL にカスタム属性クラスを関連付けます。

classdef CSCOtherAttributes < Simulink.CustomStorageClassAttributes
  properties(PropertyType = 'logical scalar')
    SupportSILPIL = true;
  end
end

カスタム属性の詳細については、Further Customize Generated Code by Writing TLC Codeおよびストレージクラスの TLC コードの記述によるデータ表現の詳細な制御を参照してください。

SIL または PIL アプリケーションインターフェイスを作成するために、コードジェネレーターは、関連付けられたカスタム TLC ファイルで関数 DataAccess と ClassAccess を呼び出し、必要な情報を取得します。コードジェネレーターは、ビルドフォルダーのビルドアーティファクトに抽出された情報を格納します。

グループ化されていないカスタムストレージクラスの場合は、次のようになります。

コードジェネレーターは、define、declare、layout、contents、address、または set の値を取る request 引数を指定して DataAccess を呼び出します。
コードジェネレーターは、次のいずれに該当する場合、DataAccess(record, "define", "", "") で返される文字列を使用して SIL アプリケーションまたは PIL アプリケーションで変数を定義します。
- 信号またはパラメーターに Imported データスコープがある。
- モデルでモデル参照コードインターフェイスが使用されている。
- モデルで最上位モデルコードインターフェイスが使用され、EnableDataOwnership が on で、カスタムストレージクラスの Owner 属性が空でなく、現在のモデルの名前と等しくない。
コードジェネレーターは、次に該当する場合、DataAccess(record, "declare", "", "") から返される文字列を使用して SIL または PIL アプリケーションで変数を定義します。
- モデルで最上位モデルコードインターフェイスが使用されている。
- 信号またはパラメーターで Exported ストレージクラスが使用されている。
- EnableDataOwnership が off であるか、EnableDataOwnership が on で、カスタムストレージクラスの Owner 属性が空またはモデル名と等しい。
- コードのパッケージ化が設定されているため、変数は model.h または model.h でインクルードされるヘッダーファイルで宣言されません。

グループ化されているカスタムストレージクラスの場合は、次のようになります。

コードジェネレーターは、layout、address、または set の値を取る request 引数を指定した DataAccess を呼び出します。
コードジェネレーターは、groupTypeDeclDefn の値を取る request 引数を指定した ClassAccess を呼び出します。
次のいずれかに該当する場合は、グループ化されたタイプ (struct) 定義とグループ化された変数の extern 宣言を指定しなければなりません。
- 信号またはパラメーターに Imported データスコープがある。
- モデルでモデル参照コードインターフェイスが使用されている。
- モデルで最上位モデルコードインターフェイスが使用され、EnableDataOwnership が on で、カスタムストレージクラスの Owner 属性が空でなく、現在のモデルの名前と等しくない。
カスタムストレージクラスに関連付けられたヘッダーファイルで、HeaderFile 属性、または model.h ファイルを通じてインクルードするカスタムコードを使用して、定義と宣言を指定します。SIL または PIL アプリケーションで変数を定義するために、コードジェネレーターは ClassAccess(record, "groupTypeDeclDefn") から返される文字列を使用します。
静的初期化では、データスコープが Exported の場合に生成される順序とは異なる struct 要素の順序を前提とすることができます。コードジェネレーターは ClassAccess(record, "groupTypeDeclDefn") のクエリを実行するときに、カスタムストレージクラスのデータ初期化属性を値 None で一時的にオーバーライドします。

SIL アプリケーションまたは PIL アプリケーションがアドレスでコード内の変数にアクセスできるかどうかを判断するために、コードジェネレーターは DataAccess(record, "layout", "", "") から返される要素を使用します。開発用コンピューターとターゲットハードウェア間で入力ポートまたは出力ポート、調整可能なパラメーター、あるいはグローバルデータストアメモリ値を転送するアプリケーション内の機能を作成するために、コードジェネレーターは次からの出力を使用します。

最初に返される要素が scalar、vector、row-mat、または col-mat の場合は DataAccess(record, "address", idx, reim)。
最初に返される要素が other の場合は DataAccess(record, "contents", idx, reim) (または DataAccess(record, "set", idx, reim))。

コードジェネレーターは、row-mat および col-mat の場合、行列はそれぞれ行優先の形式で格納されると仮定します。この仮定は、モデルの残りの部分の配列レイアウトには依存しません。コードジェネレーターは、カスタムストレージクラスで実装されたストレージの配列レイアウトがモデルの残りの部分と異なる場合、カスタムストレージファイルに関連付けられている TLC ファイルによって必要な変換が実行されると仮定します。

タイプが Other のカスタムストレージクラスと関連付けられているカスタム TLC ファイルを作成して、(要求されたコードフラグメントを返すのに加え) 他の関数を実行できます。たとえば、カスタムファイルに直接書き込むか、ベースワークスペースの状態を変更する MATLAB 関数を呼び出します。DataAccess または ClassAccess が呼び出されたときにこれらの関数を必ずしも実行するわけではない場合は、TLC 関数 LibIsAccessingCustomDataForSILPIL(record) を使用して、ターゲットコードの生成と、SIL アプリケーションまたは PIL アプリケーションの作成用のコードフラグメントの要求を区別します。次に例を示します。

...
%case "contents"
  %if !LibIsAccessingCustomDataForSILPIL(record)
    %matlab functionWithSideEffects()
  %endif
%return LibDefaultCustomStorageContents(record, idx, reim)
...

カスタムストレージクラスのその他の制限も参照してください。

AUTOSAR ランタイム環境

最上位モデルと Model ブロック SIL/PIL および SIL/PIL ブロックのシミュレーションを使用して、AUTOSAR ソフトウェアコンポーネントのモデルベースのテストを実行できます。ソフトウェアによって、AUTOSAR ソフトウェアコンポーネントの生成コードと基本のコンポーネント固有の AUTOSAR ランタイム環境 (RTE) がリンクされてテストアプリケーションが作成されます。このアプリケーションでは、AUTOSAR ソフトウェアコンポーネントによって実行された AUTOSAR API の呼び出しがテストされます。

参照モデルを含む最上位の AUTOSAR ソフトウェアコンポーネントの場合は、最上位モデルまたは Model ブロック ([コードインターフェイス] が [最上位モデル] に設定されている) の SIL シミュレーションまたは PIL シミュレーションを実行できます。シミュレーションで、ソフトウェアにより次が行われます。

参照モデルのコンパイル前に、AUTOSAR RTE ヘッダーファイルが生成される。
参照モデルのコンパイル用の RTE インクルードパスが提供される。

最上位の AUTOSAR SWC 内の参照モデルに対して Model ブロック ([コードインターフェイス] が [モデル参照] に設定されている) の SIL シミュレーションまたは PIL シミュレーションを実行することもできます。この場合は、シミュレーションを実行する前に、親コンポーネントを作成して RTF ヘッダーファイルを生成しなければなりません。親コンポーネントを作成しないと、SIL シミュレーションまたは PIL シミュレーションが失敗します。