Main Content

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

C コード生成のためのコントロール アルゴリズム モデルの準備

コントロール アルゴリズム モデルにコードを生成し、生成したコードを既存のシステムに統合して、シミュレーションと実行可能ファイルの結果を検証します。

モデルの理解

この例では動作と構造の観点からモデルを説明します。例ではコード生成のためのモデルの構成方法およびコード生成の方法も説明します。以下の方法について説明します。

  • モデル例の機能的な動作について理解する。

  • モデルの検証方法について理解する。

  • モデル チェック ツールに精通する。

  • コード生成に影響するコンフィギュレーション オプションに精通する。

  • モデルからコードを生成します。

モデルの機能設計の理解

この例では、スロットル コントローラーの単純なモデルを使用します。このモデルは冗長性を特徴としていますが、安全を最重要視するドライブ バイ ワイヤ アプリケーションには一般的です。このモデルでは、アルゴリズム設計の標準的なモデル構造と基本ブロックのセットが強調されています。

現在の設定では、モデルが生成するコードは量産ターゲット システム用には設定されていません。この例では、ターゲットの構成を変更し、生成されたコードの形式に対する変化を観測します。

最上位モデルの検証

モデル例を開きます

最上位モデルの構成は以下のとおりです。

  • 4 つのサブシステム (PI_ctrl_1PI_ctrl_2Define_Throt_ParamPos_Command_Arbitration)。

  • 最上位入力 (pos_rqstfbk_1fbk_2)。

  • 最上位出力 (pos_cmd_onepos_cmd_twoThrotComm)。

  • 信号の経路指定。

  • 変形させないブロック。変換ブロックは Sum ブロックや Integrator ブロックのように信号の値を変化させます。

レイアウトは基本モデルの構成スタイルを示します。

  • 信号の経路指定操作から計算を分離 (ラインとバス)

  • サブシステムへ分割

このスタイルはさまざまなモデル タイプに適しています。

サブシステムの検証

2 つのサブシステムは、PI コントローラーの PI_ctrl_1PI_ctrl_2 を表しています。サブシステムは同じ内容をもち、ここでは同じデータを使用します。後でこのサブシステムを使用してコード ジェネレーターが再利用可能な関数を作成するプロセスを学習します。

再利用を目的とした関連するブロックやモデルのグループである "ライブラリ" から、PI コントローラーを取得します。モデルのインクルードと再利用には 2 つの方法があり、ライブラリはそのうちの 1 つを提供します。2 番目のメソッドであるモデル参照については、このシリーズの後半で説明します。

モデル内でライブラリ ブロックを使用する場合、モデル内でブロックのインスタンスは編集できません。代わりに、ライブラリでブロック定義を編集します。これにより、異なるモデル間でもブロックのインスタンスが同一になります。

PI_ctrl_1 サブシステムを開きます。

Stateflow® チャート Pos_Command_Arbitration は 2 つのコマンド信号の基本エラー チェックを行います。コマンド信号が離れすぎている場合、チャートは出力を fail_safe 位置に設定します。

Pos_Command_Arbitration を開きます。

コード生成用のモデル コンフィギュレーション パラメーター設定の確認

コード生成用のモデルを準備するには、Embedded Coder アプリを開きます。次に、コード生成モデル コンフィギュレーション パラメーターを設定します。パラメーターにより、コード ジェネレーターがコードの生成に使用する方法と結果のコード形式が決定します。

コード生成の目的

モデル コンフィギュレーション パラメーターを手動で設定することができます。あるいは、自動的にモデル コンフィギュレーション パラメーターを設定する事前定義された目的を選択することもできます。

以下のように、ハイレベルなコード生成の目的を選択できます。

  • 実行効率性

  • ROM 効率性

  • RAM 効率性

  • トレーサビリティ

  • 安全対策

  • デバッグ

各目的は、現在のモデル コンフィギュレーション パラメーターを目的の推奨値を基準にしてチェックします。各目的には一連のコード生成アドバイザー チェックも含まれます。これらの追加のチェックを使用して、モデル コンフィギュレーション パラメーターが目的を満たすコードを作成するように設定されていることを検証できます。

目的によって作成された推奨事項の一部は、コード生成アドバイザー チェックと競合します。目的を選択する順序によって、結果が決定します。Simulink® は優先順位の高い目的を満たすことで、競合を解決します。

次の図は、優先順位を Execution efficiency > ROM efficiency > RAM efficiency に設定する方法を示しています。ダイアログ ボックスを開くには、[コンフィギュレーション パラメーター] ダイアログ ボックスで、[コード生成] ペインを選択します。次に、[目的の設定] をクリックします。

コード生成アドバイザーを実行して、指定した目的に基づいてモデルをチェックすることができます。コード生成アドバイザーを開くには、[C コード] タブで [C/C++ コード アドバイザー] をクリックします。

コード生成アドバイザーにより、選択した目的に基づいてチェックのリストが作成されます。最初のチェックでモデル コンフィギュレーション パラメーターの現在値がレビューされ、目的に基づいて代替値が提案されます。チェックにより、パラメーターが自動的に推奨値に設定されます。

手動設定オプション

モデルの [コンフィギュレーション パラメーター] ダイアログ ボックスでは、以下のペインがコード生成に関連します。

  • ソルバー

  • ハードウェア実行

  • コード生成

ソルバー

[ソルバー] ペインを開きます。

  • モデル用のコードを生成するには、モデル コンフィギュレーション パラメーター [タイプ]Fixed-step に設定しなければなりません。

  • パラメーター [固定ステップ サイズ] によってシステムの基本レートが設定されます。パラメーターをシステム内のレートの最小公倍数に設定します。

  • パラメーター [ソルバー] によってコード ジェネレーターが使用する積分アルゴルズムが制御されます。

  • システム内の各レートのエントリポイント関数を生成するには、パラメーター [各離散レートを個別のタスクとして扱う] を選択します。

ハードウェア実行

[ハードウェア実行] ペインを開きます。

ハードウェア実行パラメーターを使用してハードウェア ボードを指定します。Simulink® は、ボードの選択に基づいて、ペインのその他の設定を調整します (非表示のマイクロプロセッサ デバイスの詳細など)。ワード サイズやバイト順などの非表示のパラメーター設定を表示または調整するには、[デバイスの詳細] をクリックします。

コード生成

[コード生成] ペインを開きます。

[コード生成] ペインを使用してシステム ターゲット ファイルと最適化を指定します。この例では、Embedded Coder® システム ターゲット ファイル (ert.tlc) を使用します。このシステム ターゲット ファイルを拡張して、カスタマイズされた設定を作成できます。[コード生成] ペインとそのサブペインの基本パラメーターの一部には次が含まれます。

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

  • ert.tlc - "Base" Embedded Coder®

  • grt.tlc - "Base" Generic Real-Time Target

  • ハードウェア固有のターゲット

make ファイル

コード最適化

  • 使用されていない分岐をコードから削除し、一時変数の作成を制御します。

  • 明示的な初期化コードをもつ信号を制御します。

  • オーバーフローとゼロ除算の保護コードの使用を有効または無効にします。

コード形式オプション

  • かっこの使用

  • ヘッダー ファイル情報

  • 変数命名規則

カスタム コードのインクルード

  • C ファイル

  • H ファイル

  • オブジェクト ファイル

  • フォルダー パス

ASAP2 ファイルの生成

モデル コンフィギュレーション パラメーターの保存

モデル コンフィギュレーション パラメーターの値を MATLAB® 関数として保存できます。コマンド プロンプトで、次のように入力します。

hCs = getActiveConfigSet('rtwdemo_PCG_Eval_P1');
hCs.saveAs('ConfiguredData');

MATLAB® 関数はコンフィギュレーション パラメーター オブジェクトのテキスト表現を保存します。生成されたファイルは、アーカイブを行ったり、従来の差分ツールを使用して異なるバージョンのファイルを比較するときに使用できます。また、ファイルの内容を視覚的に検査することもできます。

関数を実行してその他のモデルのコンフィギュレーション パラメーターを設定できます。

hCs2 = ConfiguredData;
attachConfigSet('myModel', hCs2, true);
setActiveConfigSet('myModel', hCs2.Name);

シミュレーション テスト環境の理解

「テスト ハーネス」という名前の別のモデルでスロットル コントローラーのモデルをテストします。テスト ハーネスは制御アルゴリズムを評価するモデルです。次のテスト ハーネスを使用します。

  • テスト データを制御アルゴリズムから切り離す

  • プラント モデルまたはフィードバック モデルを制御アルゴリズムから切り離す

  • 制御アルゴリズム用の複数のバージョンで再利用可能な環境を提供する

テスト ハーネスを開きます

通常のシミュレーション テスト環境は以下の部分で構成されています。

  • テスト対象ユニット

  • テスト ベクトル ソース

  • 評価とログ

  • プラントまたはフィードバック システム

  • 入力と出力のスケーリング

テスト対象のユニットを強調表示します。

制御アルゴリズムは "テスト対象のユニット" です。テスト ハーネス モデルは Model ブロックから制御アルゴリズムを参照します。Model ブロックではコンポーネントを再利用できます。Model ブロックは制御アルゴリズムを名前 (rtwdemo_PCG_Eval_P1) で参照します。

Model ブロックは別のモデルに "コンパイルされた関数" としてモデルを含める (参照元) ことができます。既定では、Simulink® は参照モデルを変更時にコンパイルします。コンパイルされた関数にはライブラリに比べて以下のような利点があります。

  • 大規模なモデルのシミュレーションを高速に実行する。

  • コンパイルされた関数のシミュレーションを直接実行できる。

  • シミュレーションに必要なメモリーが小さい。モデルの複数のインスタンス (複数の Model ブロック) を追加しても、コンパイルされたモデルのコピーはメモリに 1 つだけ存在します。

テスト ベクトル ソースを強調表示します。

このモデルはテスト ベクトル ソースとして Signal Builder ブロックを使用します。そのブロックには、シミュレーション (pos_rqst) と検証サブシステムで使用する予想される結果を駆動するデータがあります。一般的なアプリケーションではシステムを十分に評価するためのテスト スイートを作成しますが、この例ではテスト データを 1 セットのみ使用します。

検証を強調表示します。

テスト ハーネスはシミュレーション結果を "ゴールデン データ" と比較します。ゴールデン データとは、モデルに望ましい動作を示すテスト結果です。このモデルでは、V&V Assertion ブロックがプラントのスロットル位置のシミュレーション結果をテスト ハーネスが提供するゴールデン値と比較します。2 つの信号の差が 5% を超える場合、テストは失敗で、Assertion ブロックはシミュレーションを中止します。

別の方法として、シミュレーションの実行が終了した後でシミュレーション データを評価することもできます。MATLAB® スクリプトまたはサードパーティのツールを使用して評価を行うことができます。実行が終了するまで待機しなければなりませんが、実行後の評価はデータの解析において大きな柔軟性があります。これら 2 つの方法を組み合わせれば、非常に柔軟で効率のよいテスト環境を得ることができます。

load_system('rtwdemo_PCGEvalHarness')
open_system('rtwdemo_PCGEvalHarness/Verification')

プラント/フィードバック システムを強調表示します。

この例では、伝達関数を正準形に分割することにより、スロットルのダイナミクスをモデル化します。プラント モデルを作成して、特定のレベルの忠実度をモデル化できます。多くのアプリケーションでは異なるプラント モデルを異なる段階のテストで使用します。

スケーリングされた入力と出力を強調表示します。

入力と出力をスケーリングするサブシステムは以下の基本関数を実行します。

  • テスト対象のユニットとプラントに送る信号を選択する。

  • エンジニアリング ユニットとテスト対象のユニットで必要なユニットとの間で信号の再スケーリングを行う。

  • プラントとテスト対象ユニットの間においてレート変換を行う。

シミュレーション テストの実行

テスト ハーネス モデルのシミュレーションを実行するには、[開始] または次のハイパーリンクをクリックします。

テスト ハーネスを実行します。

はじめてテスト ハーネスを実行する場合は、Simulink® でその参照モデルがコンパイルされていなければなりません。コマンド ウィンドウでコンパイルの進行状況を監視できます。

モデルのシミュレーションが終了すると、Simulink® はプロット図に結果を表示します。

sim('rtwdemo_PCGEvalHarness')

右下のプロット図は期待される (ゴールデン) スロットルの位置とプラントで計算されたスロットルの位置の差を示しています。

コードの生成

コードを生成するには、Embedded Coder アプリを開きます。次のいずれかの手法を使用します。

  • モデル内で Ctrl + B キーを押す。

  • [C コード] タブで、[ビルド] または [コード生成] を選択します。

  • 次のハイパーリンクをクリックする。

モデルのコードを生成します。

コード ジェネレーターによって複数のファイルが生成されます。結果コードは計算面では効率的ですが、量産環境に統合できるほど整理されていません。

生成されたコードの検査

コード ジェネレーターによって作成される複数のファイルは、[コード] ビューまたはコード生成レポートで確認できます。標準の C 定義ファイルとヘッダー ファイルの他に、コード ジェネレーターによって HTML ファイル セットも生成されます。HTML ファイルはコードとモデル間のハイパーリンクになります。

モデル エクスプローラーで HTML コード ブラウザーを開きます。

生成されたコードでは次のことに注意してください。

  • コントローラー コードは ModelName_step という名前の関数に含まれており、ファイル rtwdemo_PCG_Eval_P1.c 内にあります。

  • コード ジェネレーターでは複数のブロックの演算が 1 つのコードのステートメントに畳み込まれています。

  • 関数 ModelName_initialize は変数を初期化します。

  • データ構造体はモデル データを定義します (たとえば rtwdemo_PCG_Eval_P1_U.pos_rqst)。

  • rtwdemo_PCG_Eval_P1.c: ステップと初期化関数を定義する C ファイル

  • ert_main.c: 単純なスケジューラを含む例のメイン ファイル

  • rtwdemo_PCG_Eval_P1.h: Simulink® Coder™ データ構造体の型定義が含まれる H ファイル

  • PCG_Eval_p1_private.h: 生成したコードでのみ使用するデータを宣言するファイル

  • rtwdemo_PCG_Eval_P1_types.h: リアルタイム モデル データ構造体を宣言する H ファイル

このシリーズの次の例については、生成コードのデータ インターフェイスの構成を参照してください。

関連するトピック