Main Content

このページの翻訳は最新ではありません。ここをクリックして、英語の最新版を参照してください。

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

生成コードのメトリクスを収集します。

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 (DO Qualification Kit) の 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 シミュレーションでは、スタンドアロンのコード インターフェイスが生成されます。コードが存在する場合、シミュレーションではモデルのスタンアロン コードが呼び出されます。コードが存在しない場合、スタンドアロン コードが生成されます。

Model ブロック

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

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

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

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

項目情報
代数ループ

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

  • コンポーネントのルート レベルにある信号 (I/O 境界上)。

  • ベース ワークスペースまたはデータ ディクショナリのパラメーター。モデル ワークスペースのパラメーターの場合は、次のようになります。

    • 最上位モデルの SIL/PIL および SIL/PIL ブロック シミュレーションではストレージが定義される。

    • Model ブロックの SIL/PIL シミュレーションではストレージが定義されない。ストレージを定義し、MATLAB の値と一致する初期値を指定しなければなりません。

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

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

  • 内部信号 (I/O 境界上にない)

  • ローカル データ ストア

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

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

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

SIL シミュレーションおよび PIL シミュレーションは、GetSet カスタム ストレージ クラスをサポートします。SIL/PIL テスト ハーネスでは、シミュレーション中に使用される関数 GetSet の 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 ファイルで関数 DataAccessClassAccess を呼び出し、必要な情報を取得します。コード ジェネレーターは、ビルド フォルダーのビルド アーティファクトに抽出された情報を格納します。

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

  • コード ジェネレーターは、definedeclarelayoutcontentsaddress、または set の値を取る request 引数を指定して DataAccess を呼び出します。

  • コード ジェネレーターは、次のいずれに該当する場合、DataAccess(record, "define", "", "") で返される文字列を使用して SIL アプリケーションまたは PIL アプリケーションで変数を定義します。

    • 信号またはパラメーターに Imported データ スコープがある。

    • モデルでモデル参照コード インターフェイスが使用されている。

    • モデルで最上位モデル コード インターフェイスが使用され、EnableDataOwnershipon で、カスタム ストレージ クラスの Owner 属性が空でなく、現在のモデルの名前と等しくない。

  • コード ジェネレーターは、次に該当する場合、DataAccess(record, "declare", "", "") から返される文字列を使用して SIL または PIL アプリケーションで変数を定義します。

    • モデルで最上位モデル コード インターフェイスが使用されている。

    • 信号またはパラメーターで Exported ストレージ クラスが使用されている。

    • EnableDataOwnershipoff であるか、EnableDataOwnershipon で、カスタム ストレージ クラスの Owner 属性が空またはモデル名と等しい。

    • コードのパッケージ化が設定されているため、変数は model.h または model.h でインクルードされるヘッダー ファイルで宣言されません。

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

  • コード ジェネレーターは、layoutaddress、または set の値を取る request 引数を指定した DataAccess を呼び出します。

  • コード ジェネレーターは、groupTypeDeclDefn の値を取る request 引数を指定した ClassAccess を呼び出します。

  • 次のいずれかに該当する場合は、グループ化されたタイプ (struct) 定義とグループ化された変数の extern 宣言を指定しなければなりません。

    • 信号またはパラメーターに Imported データ スコープがある。

    • モデルでモデル参照コード インターフェイスが使用されている。

    • モデルで最上位モデル コード インターフェイスが使用され、EnableDataOwnershipon で、カスタム ストレージ クラスの Owner 属性が空でなく、現在のモデルの名前と等しくない。

    カスタム ストレージ クラスに関連付けられたヘッダー ファイルで、HeaderFile 属性、または model.h ファイルを通じてインクルードするカスタム コードを使用して、定義と宣言を指定します。SIL または PIL アプリケーションで変数を定義するために、コード ジェネレーターは ClassAccess(record, "groupTypeDeclDefn") から返される文字列を使用します。

  • 静的初期化では、データ スコープが Exported の場合に生成される順序とは異なる struct 要素の順序を前提とすることができます。コード ジェネレーターは ClassAccess(record, "groupTypeDeclDefn") のクエリを実行するときに、カスタム ストレージ クラスのデータ初期化属性を値 None で一時的にオーバーライドします。

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

  • 最初に返される要素が scalarvectorrow-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 シミュレーションが失敗します。

関連するトピック