リリース間のコード統合

Embedded Coder^® ライセンスをお持ちの場合、ソースモデルがシングルレートで、C コードが次から生成された場合に、以前のリリース (R2010a 以降) から生成された C コードを現在のリリースから生成されるコードと統合できます。

[再利用できない関数] コードインターフェイスを使用する最上位モデルまたはサブシステムのビルドプロセス。
エラーステータスの監視を非表示にする (SuppressErrorStatus を on にする) 単一または複数インスタンスのモデル参照ビルドプロセス。

変更せずに既存のコードを再利用できる場合、再検証のコストを削減することができます。

ワークフロー

次の制御システムモデルについて検討します。

Controller Model ブロックは次の 3 つのコンポーネントで構成されるモデルを参照します。

P1 は以前のリリース (たとえば R2015b) で開発されたモデルを参照する Model ブロックです。スタンドアロンのコードインターフェイスをもつ生成されたモデルコードが、P1_ert_rtw フォルダーにあります。
C1 は現在のリリースで開発中のモデルを参照する Model ブロックです。
P2 は以前のリリース (たとえば R2016a) で開発されたサブシステムブロックです。生成されたサブシステムコードが P2_ert_rtw フォルダーにあります。
P3 は以前のリリース (たとえば R2016b) で開発されたモデルを参照する Model ブロックです。モデル参照コードインターフェイスをもつ生成されたモデルコードが、slprj/ert/P3 フォルダーにあります。

以前のリリースからのコードと現在のリリースから生成されるコードを統合するには、次のワークフローを使用します。

既存の共有コードフォルダーを指定する
既存のフォルダー (管理者が維持および更新している検証済みコードのライブラリなど) から共有コードを再利用するように指定できます。現在のリリースでコード生成が必要なモデルコンポーネントの共有コードフォルダーを指定します。たとえば、Controller や C1 です。
[コンフィギュレーションパラメーター] ダイアログボックスの [既存の共有コード] フィールドに、共有コードフォルダーの絶対パスを入力します。
コンポーネントを現在のリリースにインポートする
以前のリリースの生成済みコンポーネントコードを現在のリリースでソフトウェアインザループ (SIL) ブロックまたはプロセッサインザループ (PIL) ブロックとしてインポートします。以下に例を示します。
```
crossReleaseImport(folderPathForP1_ert_rtw,'Controller', ...
'SimulationMode','SIL');
crossReleaseImport(folderPathForP2_ert_rtw,'Controller', ...
'SimulationMode','SIL');
crossReleaseImport(folderPathForP3,'Controller', ...
'SimulationMode','SIL');
```
現在の作業フォルダーで、関数 crossReleaseImport は、次のソフトウェアインザループ (SIL) ブロックとサブフォルダーを含む xrel サブフォルダーを作成します。
- P1_R2015b_sil と P1_R2015b_sil_resources
- P2_R2016a_sil と P2_R2016a_sil_resources
- P3_R2016b_sil および P3_R2016b_sil_resources
コンポーネントを現在のリリースモデルに組み込む
Simulink^® エディターまたは pil_block_replace コマンドを使用して、コンポーネントを SIL ブロックまたは PIL ブロックに置き換えます。たとえば、次のように置き換えます。
- P1 を P1_R2015b_sil。
- P2 を P2_R2016a_sil。
- P3 を P3_R2016b_sil。
モデルのシミュレーションを実行すると、SIL ブロックまたは PIL ブロックを介して以前のリリースコードのシミュレーションが実行されます。
Controller モデルをビルドするときに (slbuild('Controller'))、SIL ブロックまたは PIL ブロックで表現されるコンポーネントの新しいコードをコードジェネレーターは生成しません。モデルコードは以前のリリースで生成されたコードを呼び出します。
Simulink Code Inspector™ は、クロスリリース SIL ブロックまたは PIL ブロックに対する呼び出しサイトでの検証をサポートします。ブロックは必要な関数呼び出しの仕様を提供します。この仕様は、生成コードから派生されます。解析時に、Simulink Code Inspector は必要な関数呼び出しとブロックの動作を比較します。解析の制限の詳細については、S-Function (Simulink Code Inspector)を参照してください。

制限

リリース間コード統合ワークフローでは以下はサポートされません。

ERT コードのエクスポート関数モデル
異なるリリースによって生成された ERT コードの境界を越える Simulink Function ブロックおよび Function Caller ブロック。
R2010a よりも前のリリースの生成コードの統合。
現在のリリースの生成コードの以前のリリースへのインポート (上位互換性)。
ブロックセットライブラリファイルなど、前のリリースの MATLAB^® ルートフォルダーにあるファイルのエクスポート。
インラインでない S-Function をもつモデルから生成されたコードのエクスポートおよびインポート。
C-API。

モデルビルドプロセスの最後に、統合モデル (Controller など) によって直接使用される共有ファイルがコード生成レポートに表示されます。このレポートにはモデルのコンポーネント (たとえば P1 や P2) によって使用される共有ファイルは表示されません。

モデルに以下の場合:

クロスリリース SIL または PIL ブロック。ラピッドアクセラレータモードのシミュレーションは実行できません。
クロスリリース SIL ブロックまたは PIL ブロックが含まれるモデルを参照する Model ブロック。アクセラレータモードまたはラピッドアクセラレータモードのシミュレーションは実行できません。

以下を実行できます。

クロスリリース SIL ブロックまたは PIL ブロックが含まれるモデルの最上位モデルの SIL シミュレーション。モデルにはクロスリリース AUTOSAR Model ブロックを含めてはなりません。
クロスリリース SIL ブロックまたは PIL ブロックが含まれる参照モデルの Model ブロックの SIL シミュレーション。参照モデルにはクロスリリース AUTOSAR Model ブロックを含めてはなりません。

クロスリリース AUTOSAR コード統合に関するその他の制限の詳細については、前のリリースからの AUTOSAR コードのインポートを参照してください。

`Simulink.Bus` のサポート

クロスリリース ERT コード統合でデータ型としてバスオブジェクトを使用するには、次のいずれかの方法を使用します。

方法コードのエクスポートコードのインポート

自動

方法	コードのエクスポート	コードのインポート
自動	以前のリリースで、コードを生成する前に、`Simulink.Bus` オブジェクトの `DataScope` プロパティを `Auto` に設定します。`HeaderFile` プロパティに値を代入しないでください。コードジェネレーターは `Simulink.Bus` データ型の定義を既定のヘッダーファイルに作成します。このファイルはモデルのコード生成フォルダーにあります。	現在のリリースでは、`crossReleaseImport` を実行する前に `Simulink.Bus` オブジェクトの `DataScope` プロパティを `Auto` に設定します。統合モデルをビルドするときに、ビルドプロセスはインポートされたコード内のヘッダーファイルから `Simulink.Bus` のデータ型を使用します。
エクスポートされたバス	以前のリリースでは、コードを生成する前に `Simulink.Bus` オブジェクトの次のプロパティを指定します。 `DataScope` — `[エクスポート]` に設定します。 `HeaderFile` — `prevRelBusType` のようなファイル名を指定します。コードジェネレーターによって共有ユーティリティコードフォルダーに `prevRelBusType.h` が作成されます。このヘッダーファイルには `Simulink.Bus` データ型の定義が含まれています。`sharedCodeUpdate` を使用して、`ExistingSharedCode` によって指定される共有コードフォルダーに `prevRelBusType.h` を追加します。 R2010a と R2010b では、`DataScope` プロパティは使用できません。`HeaderFile` プロパティに値を代入しないでください。コードジェネレーターは `Simulink.Bus` データ型の定義を `modelName_types.h` に作成します。このファイルはモデルのコード生成フォルダーにあります。	現在のリリースでは、`crossReleaseImport` を実行する前に `Simulink.Bus` オブジェクトの `DataScope` プロパティを `[インポート]` に設定します。インポートされる SIL ブロックまたは PIL ブロックを組み込む統合モデルをビルドするときに、ビルドプロセスでは `prevRelBusType.h` の `Simulink.Bus` データ型の定義を使用します。インポートされるコードが R2010a または R2010b からのものである場合、`Simulink.Bus` オブジェクトの次のプロパティを指定します。 `DataScope` — `[インポート]` に設定します。 `HeaderFile` — インポートされるコードフォルダーにある `modelName_types.h` のパスを設定します。統合モデルをビルドするときに、ビルドプロセスでは `modelName_types.h` の `Simulink.Bus` データ型の定義を使用します。
インポートされたバス	以前のリリースでは、コードを生成する前に `Simulink.Bus` オブジェクトの次のプロパティを指定します。 `DataScope` — `[インポート]` に設定します。 `HeaderFile` — `Simulink.Bus` データ型の定義が含まれているファイルのパスを指定します (`aBusType.h` など)。 R2010a と R2010b では、`DataScope` プロパティは使用できません。`HeaderFile` プロパティに `Simulink.Bus` データ型の定義が含まれているファイルのパスを指定します (`aBusType.h` など)。	現在のリリースでは、生成コードをインポートした後に `Simulink.Bus` を変更する必要はありません。インポートされる SIL ブロックまたは PIL ブロックを組み込む統合モデルをビルドするときに、ビルドプロセスでは `aBusType.h` の `Simulink.Bus` データ型の定義を使用します。インポートされるコードが R2010a または R2010b からのものである場合、`Simulink.Bus` オブジェクトの次のプロパティを指定します。 `DataScope` — `[インポート]` に設定します。 `HeaderFile` — `aBusType.h` に設定します。統合モデルをビルドするときに、ビルドプロセスでは `aBusType.h` の `Simulink.Bus` データ型の定義を使用します。

以前のリリースで、コードを生成する前に、Simulink.Bus オブジェクトの DataScope プロパティを Auto に設定します。HeaderFile プロパティに値を代入しないでください。

コードジェネレーターは Simulink.Bus データ型の定義を既定のヘッダーファイルに作成します。このファイルはモデルのコード生成フォルダーにあります。

現在のリリースでは、crossReleaseImport を実行する前に Simulink.Bus オブジェクトの DataScope プロパティを Auto に設定します。

統合モデルをビルドするときに、ビルドプロセスはインポートされたコード内のヘッダーファイルから Simulink.Bus のデータ型を使用します。

エクスポートされたバス

以前のリリースでは、コードを生成する前に Simulink.Bus オブジェクトの次のプロパティを指定します。

DataScope — [エクスポート] に設定します。
HeaderFile — prevRelBusType のようなファイル名を指定します。

コードジェネレーターによって共有ユーティリティコードフォルダーに prevRelBusType.h が作成されます。このヘッダーファイルには Simulink.Bus データ型の定義が含まれています。sharedCodeUpdate を使用して、ExistingSharedCode によって指定される共有コードフォルダーに prevRelBusType.h を追加します。

R2010a と R2010b では、DataScope プロパティは使用できません。HeaderFile プロパティに値を代入しないでください。コードジェネレーターは Simulink.Bus データ型の定義を modelName_types.h に作成します。このファイルはモデルのコード生成フォルダーにあります。

現在のリリースでは、crossReleaseImport を実行する前に Simulink.Bus オブジェクトの DataScope プロパティを [インポート] に設定します。

インポートされる SIL ブロックまたは PIL ブロックを組み込む統合モデルをビルドするときに、ビルドプロセスでは prevRelBusType.h の Simulink.Bus データ型の定義を使用します。

インポートされるコードが R2010a または R2010b からのものである場合、Simulink.Bus オブジェクトの次のプロパティを指定します。

DataScope — [インポート] に設定します。
HeaderFile — インポートされるコードフォルダーにある modelName_types.h のパスを設定します。

統合モデルをビルドするときに、ビルドプロセスでは modelName_types.h の Simulink.Bus データ型の定義を使用します。

インポートされたバス

以前のリリースでは、コードを生成する前に Simulink.Bus オブジェクトの次のプロパティを指定します。

DataScope — [インポート] に設定します。
HeaderFile — Simulink.Bus データ型の定義が含まれているファイルのパスを指定します (aBusType.h など)。

R2010a と R2010b では、DataScope プロパティは使用できません。HeaderFile プロパティに Simulink.Bus データ型の定義が含まれているファイルのパスを指定します (aBusType.h など)。

現在のリリースでは、生成コードをインポートした後に Simulink.Bus を変更する必要はありません。

インポートされる SIL ブロックまたは PIL ブロックを組み込む統合モデルをビルドするときに、ビルドプロセスでは aBusType.h の Simulink.Bus データ型の定義を使用します。

インポートされるコードが R2010a または R2010b からのものである場合、Simulink.Bus オブジェクトの次のプロパティを指定します。

DataScope — [インポート] に設定します。
HeaderFile — aBusType.h に設定します。

統合モデルをビルドするときに、ビルドプロセスでは aBusType.h の Simulink.Bus データ型の定義を使用します。

生成コード内のグローバル変数を介したルートレベル I/O

以前のリリースからインポートした ERT コードでグローバル変数を介して入力または出力ポートを実装すると、統合モデルから生成されたコードは統合モデルのポートに接続された信号のプロパティに依存します。

統合モデルの信号のマッピング先が、インポートされたコード内の信号と同じ名前をもつ、生成済みのコード変数でない場合、次のようになります。

宣言された場合は変数を定義しますが、インポートされたコード内では未定義です。
統合モデルから生成された変数と、インポートされたコード内の変数との間でデータをコピーする追加のコードを作成します。

統合モデルの信号がインポートされたコード内の信号と同じ名前をもつ変数にマップされる場合、インポートされたコードで使用される変数は統合モデルから生成されたコードによっても使用されます。信号には互換性のあるストレージクラスを使用しなければなりません。

ストレージクラスプロパティプロパティ値のサポート

タイプ [Unstructured] のみ

ストレージクラスプロパティ	プロパティ値のサポート
タイプ	`[Unstructured]` のみ
データアクセス	インポートされたコード内で `[ポインター]` 変数として実装されたポートを、統合モデルで `[直接]` ストレージクラスを介して実装された同じ名前の信号に接続することはできないインポートされたコード内で `[直接]` 変数として実装されたポートを、統合モデルで `[ポインター]` として実装された同じ名前の信号に接続することはできない
データスコープ	インポートされたコードで変数が宣言されても定義されない場合 (`[インポート]` 値を使用する信号から生成されたコードなど)、次のいずれかが必要になります。統合モデルで `[エクスポート]` 値を使用する。外部コードで変数を定義する。インポートされたコードで変数が定義される場合 (`[エクスポート]` 値を使用する信号から生成されたコードなど)、次のようになります。ルートレベルの I/O 端子に接続された統合モデル内の信号の場合: `EnableDataOwnership` コンフィギュレーションパラメーターを `on` に設定する。以下のプロパティでカスタムストレージクラスを使用する: タイプ – `[Unstructured]` データアクセス – `[直接]` データスコープ – `[エクスポート]` オーナー – 統合モデルの名前ではない、空ではない値。たとえば、値はインポートされたコンポーネントの名前にすることができる。ルートレベルの I/O 端子に接続されていない統合モデル内の信号の場合、以下のプロパティ値でカスタムストレージクラスを使用する: データスコープ - `[インポート]` データアクセス – `[直接]`

データアクセス

インポートされたコード内で [ポインター] 変数として実装されたポートを、統合モデルで [直接] ストレージクラスを介して実装された同じ名前の信号に接続することはできない

インポートされたコード内で [直接] 変数として実装されたポートを、統合モデルで [ポインター] として実装された同じ名前の信号に接続することはできない

データスコープ

インポートされたコードで変数が宣言されても定義されない場合 ([インポート] 値を使用する信号から生成されたコードなど)、次のいずれかが必要になります。

統合モデルで [エクスポート] 値を使用する。
外部コードで変数を定義する。

インポートされたコードで変数が定義される場合 ([エクスポート] 値を使用する信号から生成されたコードなど)、次のようになります。

ルートレベルの I/O 端子に接続された統合モデル内の信号の場合:
- EnableDataOwnership コンフィギュレーションパラメーターを on に設定する。
- 以下のプロパティでカスタムストレージクラスを使用する:
  - タイプ – [Unstructured]
  - データアクセス – [直接]
  - データスコープ – [エクスポート]
  - オーナー – 統合モデルの名前ではない、空ではない値。たとえば、値はインポートされたコンポーネントの名前にすることができる。
ルートレベルの I/O 端子に接続されていない統合モデル内の信号の場合、以下のプロパティ値でカスタムストレージクラスを使用する:
- データスコープ - [インポート]
- データアクセス – [直接]

グローバルデータストアを介した現在のリリースと以前のリリースのコンポーネント間のやり取り

現在のリリースと以前のリリースのコンポーネントは、MATLAB ベースワークスペースまたは Simulink データディクショナリの Simulink.Signal オブジェクトに関連付けられたグローバルデータストアを介してやり取りできます。ここで説明するワークフローはクロスリリース ERT コード統合に適用されます。

コード生成の構成

以前のリリースでモデルコンポーネントコードを生成する前に、外部コードをインポートするストレージクラスを使用するようにデータストアメモリを構成します。

最上位モデルまたはサブシステムのビルドプロセスでコードを生成する場合、Simulink.Signal オブジェクトの [Storage Class] プロパティを次のいずれかのクラスに設定します。

ImportedExtern
ImportedExternPointer
[ImportFromFile] カスタムストレージクラス

モデル参照のビルドプロセスでコードを生成する場合、以下のクラスを使用することもできます。

ExportedGlobal
[ExportToFile] カスタムストレージクラス

コンフィギュレーションのインポート

現在のリリースでは、crossReleaseImport を実行する前に、インポートするコンポーネントの各グローバルデータストアに対し、MATLAB ベースワークスペースまたは Simulink データディクショナリで Simulink.Signal オブジェクトを定義します。

オブジェクト名、[データ型]、[実数/複素数]、[次元] オブジェクトプロパティの場合、インポートするコンポーネント内で対応するオブジェクトの値と一致する値を指定します。
[Storage Class] プロパティの場合、互換性のある値を指定します。以前のリリースの値が [ImportedExtern] の場合、現在のリリースに対して次のいずれかの値を指定します。
- ImportedExtern
- ExportedGlobal
- [ImportFromFile] または [ExportToFile] カスタムストレージクラス。
以前のリリースの値が [ImportedExternPointer] の場合、現在のリリースに対して [ImportedExternPointer] を指定します。
[Identifier] プロパティの場合、インポートするコンポーネント内のオブジェクトに対してプロパティが指定される場合にのみ一致する値を指定します。
Simulink.Signal オブジェクトを保存します。このオブジェクトは、インポートした SIL または PIL ブロックをシミュレートまたはビルドするたびに必要になります。

詳細については、生成されたコード内のデータストアを参照してください。

パラメーターの調整

クロスリリースの ERT コード統合ワークフローは、以前のリリースからの調整可能なパラメーターを使用するコンポーネントコードを含む統合モデルでパラメーターの調整をサポートしています。

現在のリリースで、インポートするコンポーネントの調整可能な各パラメーターに対して crossReleaseImport を実行する前に、次を行います。

MATLAB ベースワークスペースまたは Simulink データディクショナリで Simulink.Parameter オブジェクトを定義します。
オブジェクト名、[データ型]、[実数/複素数]、[次元] オブジェクトプロパティに、以前のリリースのオブジェクト値に一致する値を指定します。インポートしたソースコードの変数にオブジェクトと同じ名前がない場合、[Identifier] プロパティに対して、変数名と一致する値を指定します。
以前のリリースのオブジェクトで GetSet カスタムストレージクラスを使用する場合、次を指定します。
- [Storage Class] オブジェクトプロパティと一致する値。
- get アクセス関数と set アクセス関数を定義するヘッダーファイル。詳細については、Control Data Representation by Configuring Storage Class PropertiesとAccess Data Through Functions with Storage Class GetSetを参照してください。
以前のリリースからの GetSet カスタムストレージクラスのサポートは R2011a 以降のリリースにのみ適用されます。

以前のリリースで最上位モデルまたはサブシステムのビルドプロセスで生成されたコードの場合、これらの制限は以下に適用されます。

以前のリリースの Simulink.Parameter オブジェクトで指定した調整可能なパラメーターが ExportedGlobal に設定されたストレージクラスをもち、現在のリリースの Simulink.Parameter オブジェクトのストレージクラスも ExportedGlobal である場合、統合モデルをビルドするときにエラーが発生します。
Mac オペレーティングシステムでは、以前のリリースの Simulink.Parameter オブジェクトで指定された調整可能なパラメーターが ExportedGlobal に設定されたストレージクラスをもっていると、現在のリリース (同じ名前またはエイリアスをもつ) の Simulink.Parameter オブジェクトのストレージクラスも ImportedExtern である場合、統合モデルのビルドはできません。この制限を回避するには、既定の設定を次のように変更します。
1. 既定のツールチェーンからビルドツールを取得します。
  tc = coder.make.getDefaultToolchain; cComp = tc.getBuildTool('C Compiler');
2. C コンパイラ標準オプションを抽出します。
  stdMaps = cComp.SupportedStandard.getLangStandardMaps; optionValues = stdMaps.getCompilerOptions('*');
3. C および C++ コンパイラの標準オプションから -fno-common を削除します。
  optionToRemove = '-fno-common'; optionsToKeep = strrep(optionValues, optionToRemove, ''); c_standard_opts_id = '$(C_STANDARD_OPTS)'; custToolChainOpts = get_param(model,'CustomToolchainOptions'); custToolChainOpts{2} = ... strrep(custToolChainOpts{2}, c_standard_opts_id, optionsToKeep); set_param(model, 'CustomToolchainOptions',custToolChainOpts);

再利用可能な参照モデルから生成されたコードの複数のインスタンスの使用

再利用可能な参照モデルを使用すると、親モデル内の参照モデルの各インスタンスに対して一意のモデル引数値を指定できます。再利用可能な参照モデル用に以前生成したコードを、パラメーター化されたクロスリリース SIL ブロックまたは PIL ブロックとして現在のリリースにインポートしてから、ブロックの複数のインスタンスを統合モデルに挿入します。各ブロックのインスタンスに対して、一意のモデル引数値を指定できます。

既存の共有コードフォルダーを更新します。
```
sharedCodeUpdate(sourceFolder,destinationFolder)
```
再利用可能な参照モデル用に生成されたコードをパラメーター化されたクロスリリースブロック (たとえば SIL ブロック) として現在のリリースにインポートします。
```
handleSILBlock = crossReleaseImport(reusableReferencedModelcodeLocation, ...
 configSetIntegrationModel, 'SimulationMode', 'SIL');
```

統合モデルで、たとえば、参照モデルの 2 つのインスタンスをクロスリリース SIL ブロックのインスタンスに置き換えます。

open_system(integrationModel);

blockInstanceName1 = 'refModelInstanceName1';
blockinstanceName2 = 'refModelInstanceName2';

SILBlockFullName = getfullname(handleSILBlock);
replace_block(integrationModel, 'Name', blockInstanceName1, ...
              SILBlockFullName, 'noprompt');
replace_block(integrationModel, 'Name', blockInstanceName2, ...
              SILBlockFullName, 'noprompt');

再利用可能な参照モデルにモデル引数の paramA と paramB があり、参照モデルのインスタンス refModelInstanceName1 と refModelInstanceName2 の値はワークスペース変数であると仮定します。この場合、ワークスペース変数であるクロスリリースブロックインスタンスに対して引数値を指定できます。

pathToBlockInstanceName1 = [integrationModel, '/', blockInstanceName1];
pathToBlockInstanceName2 = [integrationModel, '/', blockInstanceName2];

set_param(pathToBlockInstanceName1, 'paramA', 'paramA_instName1');
set_param(pathToBlockInstanceName1, 'paramB', 'paramB_instName1');

set_param(pathToBlockInstanceName2, 'paramA', 'paramA_instName2');
set_param(pathToBlockInstanceName2, 'paramB', 'paramB_instName2');

統合モデルのブロックインスタンスに対して一意のモデル引数値を指定するには、ワークスペース変数 paramA_instName1、paramB_instName1、paramA_instName2、および paramB_instName2 に値を割り当てます。

現在のリリースのモデルコンポーネントと以前のリリースの生成コードのシミュレーション動作の比較

以前のリリースでは、モデルコンポーネントを開発し、コンポーネントのコードを生成して、生成したコードをテストおよび展開したものとします。そこに、現在のリリースで、モデルコンポーネントに機能を追加し、システム開発およびコード生成でそのモデルコンポーネントを使用するとします。処理を進める前に、モデルコンポーネントと以前のリリースの生成コードの機能的な動作を比較できます。

モデルコンポーネントと以前のリリースの生成コード間の数値的等価性をテストするには、Simulink Test™ を使用します。テストマネージャー (Simulink Test)で、back-to-back テストと出力の比較を実行できます。

モデルコンポーネントを、[シミュレーションモード] ブロックパラメーターが [ノーマル] に設定された Model ブロックとして現在のリリースにします。
Model ブロックを使用して、テスト入力データを指定する最上位モデルを作成します。
以前のリリースで生成されたコードを SIL ブロックとして現在のリリースにインポートします。
SIL ブロックで、同じテスト入力データを指定する別の最上位モデルを作成します。
テストマネージャーで、最上位モデルのシミュレーションを実行し、出力を比較する等価性のテストケースを作成します。
テストケースを実行し、結果をレビューします。

詳細については、Test Two Simulations for Equivalence (Simulink Test)を参照してください。

メモ

手順 1 で現在のリリースと以前のリリースの生成コードの動作を比較する場合は、次の Model ブロックパラメーターを指定します。

[シミュレーションモード] を [ソフトウェアインザループ (SIL)] または [プロセッサインザループ (PIL)] に設定します。
[コードインターフェイス] を [最上位モデル] に設定します。

前のリリースからの AUTOSAR コードのインポート

Embedded Coder Support Package for AUTOSAR Standard をインストールする場合、前のリリースで生成した現在のリリースの AUTOSAR コンポーネントコードにインポートできます。

crossReleaseImport を実行すると、関数は SIL ブロックまたは PIL ブロックではなくクロスリリース Model ブロックとして AUTOSAR コードをインポートします。Model ブロックの [シミュレーションモード] パラメーターは [ソフトウェアインザループ (SIL)] または [プロセッサインザループ (PIL)] に設定されます。Model ブロックを現在のリリースのモデルに組み込みます。

以下の制限が適用されます。

クロスリリースワークフローでは、NVRAM にアクセスするインスタンスごとのメモリはサポートされません。
調整可能なパラメーターは AUTOSAR キャリブレーションパラメーターまたは AUTOSAR 内部キャリブレーションパラメーターにマッピングされなければなりません。
元のモデルでバリアントまたはシンボリック次元 (次元バリアント) を使用する場合、インポートされたモデルは、前のリリースでのコード生成時に使用された同じバリアントとシンボリック次元の構成のみを使用できます。