Main Content

リリース間のコード統合

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

  • [再利用できない関数] コード インターフェイスを使用する最上位モデルまたはサブシステムのビルド プロセス。

  • エラー ステータスの監視を非表示にする (SuppressErrorStatus を on にする) 単一または複数インスタンスのモデル参照ビルド プロセス。

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

メモ

crossReleaseImport (Embedded Coder) は、直近の過去 8 リリースからのみ、生成コードのインポートをサポートします。

ワークフロー

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

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

  • P1 は以前のリリース (たとえば R2015b) で開発されたモデルを参照する Model ブロックです。スタンドアロンのコード インターフェイスをもつ生成されたモデル コードが、P1_ert_rtw フォルダーにあります。

  • C1 は現在のリリースで開発中のモデルを参照する Model ブロックです。

  • P2 は以前のリリース (たとえば R2016a) で開発されたサブシステム ブロックです。生成されたサブシステム コードが P2_ert_rtw フォルダーにあります。

  • P3 は以前のリリース (たとえば R2016b) で開発されたモデルを参照する Model ブロックです。モデル参照コード インターフェイスをもつ生成されたモデル コードが、slprj/ert/P3 フォルダーにあります。

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

  1.  既存の共有コード フォルダーを指定する

  2.  コンポーネントを現在のリリースにインポートする

  3.  コンポーネントを現在のリリース モデルに組み込む

制限

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

  • ERT コードのエクスポート関数モデル

  • 異なるリリースによって生成された ERT コードの境界を越える Simulink Function ブロックおよび Function Caller ブロック。

  • R2010a よりも前のリリースの生成コードの統合。

  • 現在のリリースの生成コードの以前のリリースへのインポート (上位互換性)。

  • ブロックセット ライブラリ ファイルなど、前のリリースの MATLAB® ルート フォルダーにあるファイルのエクスポート。

  • インラインでない S-Function をもつモデルから生成されたコードのエクスポートおよびインポート。

  • C-API (Embedded Coder)。

モデル ビルド プロセスの最後に、統合モデル (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 データ型の定義を既定のヘッダー ファイル (Embedded Coder)に作成します。このファイルはモデルのコード生成フォルダーにあります。

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

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

エクスポートされたバス

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

  • DataScope — [エクスポート] に設定します。

  • HeaderFile — ファイル名を指定します (たとえば prevRelBusType)。

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

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

現在のリリースでは、crossReleaseImport (Embedded Coder) を実行する前に 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] のみ
データ アクセス

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

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

データ スコープ

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

  • 統合モデルで [エクスポート] 値を使用する。

  • 外部コードで変数を定義する。

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

  • ルートレベルの 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 オブジェクトを定義します。

  1. オブジェクト名、[データ型]、[実数/複素数]、[次元] オブジェクト プロパティの場合、インポートするコンポーネント内で対応するオブジェクトの値と一致する値を指定します。

  2. [Storage Class] プロパティの場合、互換性のある値を指定します。以前のリリースの値が [ImportedExtern] の場合、現在のリリースに対して次のいずれかの値を指定します。

    • ImportedExtern

    • ExportedGlobal

    • [ImportFromFile] または [ExportToFile] カスタム ストレージ クラス。

    以前のリリースの値が [ImportedExternPointer] の場合、現在のリリースに対して [ImportedExternPointer] を指定します。

  3. [Identifier] プロパティの場合、インポートするコンポーネント内のオブジェクトに対してプロパティが指定される場合にのみ一致する値を指定します。

  4. Simulink.Signal オブジェクトを保存します。このオブジェクトは、インポートした SIL または PIL ブロックをシミュレートまたはビルドするたびに必要になります。

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

パラメーターの調整

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

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

  1. MATLAB ベース ワークスペースまたは Simulink データ ディクショナリで Simulink.Parameter オブジェクトを定義します。

  2. オブジェクト名、[データ型]、[実数/複素数]、[次元] オブジェクト プロパティに、以前のリリースのオブジェクト値に一致する値を指定します。インポートしたソース コードの変数にオブジェクトと同じ名前がない場合、[Identifier] プロパティに対して、変数名と一致する値を指定します。

  3. 以前のリリースのオブジェクトで 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 ブロックとして現在のリリースにインポートしてから、ブロックの複数のインスタンスを統合モデルに挿入します。各ブロックのインスタンスに対して、一意のモデル引数値を指定できます。

  1. 既存の共有コード フォルダーを更新します。

    sharedCodeUpdate(sourceFolder,destinationFolder)

  2. 再利用可能な参照モデル用に生成されたコードをパラメーター化されたクロスリリース ブロック (たとえば SIL ブロック) として現在のリリースにインポートします。

    handleSILBlock = crossReleaseImport(reusableReferencedModelcodeLocation, ...
 configSetIntegrationModel, 'SimulationMode', 'SIL');

  3. 統合モデルで、たとえば、参照モデルの 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');

  4. 再利用可能な参照モデルにモデル引数の 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');

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

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

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

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

  1. モデル コンポーネントを、[シミュレーション モード] ブロック パラメーターが [ノーマル] に設定された Model ブロックとして現在のリリースにします。

  2. Model ブロックを使用して、テスト入力データを指定する最上位モデルを作成します。

  3. 以前のリリースで生成されたコードを SIL ブロックとして現在のリリースにインポートします。

  4. SIL ブロックで、同じテスト入力データを指定する別の最上位モデルを作成します。

  5. テスト マネージャーで、最上位モデルのシミュレーションを実行し、出力を比較する等価性のテスト ケースを作成します。

  6. テスト ケースを実行し、結果をレビューします。

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

メモ

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

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

  • [コード インターフェイス] を [最上位モデル] に設定します。

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

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

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

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

  • クロスリリース ワークフローでは、NVRAM にアクセスするインスタンスごとのメモリはサポートされません。

  • 調整可能なパラメーターは AUTOSAR キャリブレーション パラメーターまたは AUTOSAR 内部キャリブレーション パラメーターにマッピングされなければなりません。

  • 元のモデルでバリアントまたはシンボリック次元 (次元バリアント) を使用する場合、インポートされたモデルは、前のリリースでのコード生成時に使用された同じバリアントとシンボリック次元の構成のみを使用できます。

参考

(Embedded Coder) | (Embedded Coder) | (Embedded Coder)

関連するトピック