このページの翻訳は最新ではありません。ここをクリックして、英語の最新版を参照してください。
イベントはアクション、遷移、または条件を表す構造です。モデルの階層構造内からイベントをブロードキャストできます。イベントは、重要な条件を検出するブロックを分割に接続して、条件が発生したときの分割の実行をスケジュールできます。スケジュール エディターでは、分割を作成および管理して、モデルの実行をスケジュールすることができます。イベントを非周期的分割にバインドし、イベントがブロードキャストされたときの実行について、優先順位に基づいてスケジュールできます。R2020b 以降、スケジュール エディターのイベントを send
キーワードを使用して Stateflow® チャートから送信できるようになりました。イベントによってシステムの作成が簡略化され、スケジュール時の柔軟性が向上します。
スケジュール エディターでは、モデルの階層構造内のモデルごとに独自の [イベント] パネルがあり、モデルとモデルの子に含まれているすべてのイベントが示されます。スケジュール エディターを開いてブロック線図を更新すると、モデル内のすべての分割とイベントがスケジュール エディターに表示されます。[イベント] パネルでは、以下を実行できます。
イベントを作成する。
イベントを削除する。
イベントの名前を変更する。
イベントを取得する。
イベントを分割にバインドする。
分割からイベントのバインドを解除する。
以下に示すように、Stateflow チャートの特定のイベントのブロードキャストに基づいて、非周期的分割の実行をスケジュールできます。
スケジュール エディターの [イベント] パネルには、イベント ツリーが表示されます。すべてのイベントの下に、そのイベントのブロードキャスターとリスナーが表示されます。
イベントが分割にバインドされている場合、イベント名は分割の左側と、[順序] テーブルの [トリガー] 列に表示されます。
モデル内およびモデルの階層構造内のイベントには一意の名前が適用されます。モデルの階層構造内では、モデル名の先頭にイベント名が付加されます。たとえば、ModelName
という名前のモデル参照にイベント E1
が含まれる場合、イベントはスケジュール エディターに ModelName.E1
として表示されます。
イベントのバインド- イベントと分割をバインドして、イベントがブロードキャストされるときに分割の実行を示すことができます。分割は単一のイベントにのみバインドできます。
優先順位に基づいた実行- イベントにバインドされた分割が、イベントを駆動する分割の前に実行されるようにスケジュールされている場合、イベントにバインドされた分割の実行は、イベントを駆動する分割の実行をプリエンプトします。トリガーされた分割の実行が、イベントを駆動する分割の後にスケジュールされている場合、トリガーされた分割は、スケジューラが実行順序で該当の位置に到達すると実行されます。
listenerPartition
は非周期的分割であり、イベント Event1
に対するリスナーです。Event1
はモデル内にある Stateflow チャートから取得され、broadcastPartition
という名前の分割の一部であると仮定します。broadcastPartition
の実行が開始されると、Event1
が発生し、その後 listenerPartition
の実行がトリガーされます。
ヒット時間- 指定されたヒット時間に非周期的分割をトリガーできます。分割にヒット時間があり、分割がイベントにバインドされている場合、ヒット時間は指定されたイベントに置き換えられます。同様に、分割がイベントにバインドされ、ヒット時間が追加されている場合、バインドされたイベントが分割から削除されます。変数で、非周期的分割のヒット時間も指定できます。あいまいな変数とイベント名の場合、イベントが優先されます。
この例では、イベントを使用して Stateflow チャートにより非周期的分割の実行をスケジュールする方法を示します。Stateflow からイベントを送信し、それらのイベントを使用して、スケジュール エディターのイベントを使用してモデルでの分割の実行を制御できます。
モデルを開く
この例では、内燃エンジンのデジタル速度制御をシミュレートします。このモデルでは、エンジンの角速度を 2 つの冗長ホール センサーを使用して測定し、ホール センサーの故障をシミュレートします。
モデルには主に次の主要コンポーネントが含まれます。
System Inputs: システムを実行する入力と信号。
Engine: 内燃エンジンの簡略表現。
Composition: ランタイム環境 (RTE) で、エンジン制御ユニット (ECU) に展開するためのデジタル コントローラー。
Crank Dual Hall Sensor: 2 つの冗長センサー sensor A
と sensor B.
のエミュレーション。
RTE Services: エンジン制御ユニットで提供されるサービスのエミュレーション。
open_system("ex_engine_speed_control_system");
システム入力
このモデルのシステム入力は、Signal Editor ブロックを使用して設計されます。ex_engine_speed_control_external_inputs.mat
ファイルには以下のシナリオが含まれています。
目的の角速度はエミュレーション全体で 2000 rpm
に設定されています。
t = 01 sec
で、速度コントローラーが有効になります。その結果、Hall sensor A
が角速度の計算に使用され、エンジン速度は 2000 rpm.
まで上がります。
t = 06 sec
で、1 つ目のホール センサーの故障が注入されます。その結果、Hall sensor B
が角速度の計算に使用されるようになり、エンジン速度は 2000 rpm.
のままになります。
t = 11 sec
で、2 つ目のセンサーの故障が注入されます。その結果、速度コントローラーは無効になり、エンジン速度は 0 まで下がります。
t = 15 sec
で、sensors A
と B
の故障が解決されます。
t = 21 sec
で、速度制御を有効にするコマンドは、1 秒間 0 になり、1 に戻ります。その結果、エンジン速度は 2000 rpm.
まで上がります。
Engine
エンジン ダイナミクスは、スロットル コマンドを受け取ってそれをトルクに変換する伝達関数と、運動を積分する 2 次積分器によって表されます。
Composition
ex_engine_speed_controller_composition
は、デジタル制御アルゴリズムを実装します。これには、以下のコンポーネントが含まれます。
ComputeRPM_A
および ComputeRPM_B:
ハードウェア割り込みとして登録される非周期的分割。Hall sensors A
および B
は、エンジン シャフトが 10 度回転するたびにこれらの分割をトリガーします。
computeThrottle and actuatorProcessing:
0.001 秒で実行される周期的分割。computeThrottle
はタイム ステップごとに RTE を照会します。
monitorMalfunction:
0.01 秒で実行される周期的分割。ComputeRPM_A
および ComputeRPM_B
の出力信号を監視して、潜在的なハードウェアの故障を特定します。故障が検出されると、RTE で指定された関数が呼び出され、故障が登録されます。
checkForRecovery:
故障が検出されると RTE によってトリガーされる非周期的分割。検出時に、checkForRecovery
は RTE により 1 秒のレートで呼び出されます。 回復が検出されると、RTE で指定された関数が呼び出されます。
スケジュール エディターを使用して、イベント checkForRecovery
、tringCrankA
および trigCrankB
が作成されて、それぞれ非周期的分割 checkForRecovery,
、ComputeRPM_A
および ComputeRPM_B
にバインドされます。これらのイベントは最上位モデルからブロードキャストされます。
クランク デュアル ホール センサー
ホール センサーは、エンジン シャフトが 10 度回転するたびに関数呼び出しを生成する Hit Crossing ブロックを使用してモデル化されます。Stateflow チャートがトリガーされると、非周期的分割 ComputeRPM_A
および ComputeRPM_B
をそれぞれ実行するためにバインドされたイベント trigCrankA
および trigCrankB,
が送信されます。
RTE サービス
RTE Services
サブシステムは、デジタル コントローラーから生成されたコードが展開されるランタイム環境で使用できる機能をエミュレートします。シミュレーションの目的で、これらのサービスは Simulink 関数を使用してエミュレートされます。
sendFailureStatus
および recoverFailureStatus
は、故障または回復が検出されたときにそれぞれ monitorMalfunctions
分割および checkForRecovery
分割によって呼び出されます。グローバルな故障ステータスが、シミュレーション目的で Data Store Memory ブロックを使用して保存されます。
getFailureMode
は、センサーのいずれかで故障が検出されているかどうかを確認するために computeThrottle
によって呼び出されます。
getTimeA
および getTimeB
は RTE クロックをシミュレーションします。
Check for Recovery
は、デジタル コントローラーの checkForRecovery
非周期的分割がトリガーされるタイミングを判定するロジックをシミュレートします。トリガーはイベント checkForRecovery
をブロードキャストして実行されます。
スケジュール エディターを開く
スケジュール エディターを開くには、[モデル化] タブの [設計] セクションで [スケジュール エディター] をクリックします。[ブロック線図の更新] を実行すると、モデルがコンパイルされ、スケジュール エディターで既存の分割が示されます。
スケジュール エディターの [イベント] パネル
Stateflow の send
キーワードでブロードキャストされたイベントは、スケジュール エディターの [イベント] パネルに表示され、これらのイベントは非周期的分割にバインドされるため、これらの分割は最上位モデルからトリガーできます。[イベント] パネルで、各イベントを展開して、そのイベントのリスナーとブロードキャスターを参照できます。アイコン はイベントのブロードキャスターを示し、アイコン
はリスナーを示します。この例では、イベント
checkForRecovery
の送信側は RTE Services
サブシステムの Stateflow チャートで、イベント trigCrankA
および trigCrankB
の送信側は、クランク デュアル ホール -> センサー A およびセンサー B の Stateflow チャートです。
[順序] パネルで、分割は実行の優先順に配置されます。ComputeRPM_A
と ComputeRPM_B
は時間的な制約があるため、優先順位は最上位になります。したがって、イベント trigCranA
および trigCrankB
がブロードキャストされると、対応する分割 ComputeRPM_A
と ComputeRPM_B
はすぐに実行されます。一方、非周期的分割 checkForRecovery
は時間的な制約が少ないため、優先順位は低くなります。したがって、イベント checkForRecovery
がブロードキャストされると、対応する分割 checkForRecovery
の実行は、優先順位の高いすべての分割の実行が完了するまで延期されます。
シミュレーション結果
モデルのシミュレーション データ インスペクターで [結果を表示] をクリックし、シミュレーションの結果を表示します。
スケジュール エディターを使用して、イベントを含むモデルのテスト ハーネスを生成できます。イベントをテスト ハーネスとともに使用すると、Test Sequence ブロックとシステム全体の間の複雑な結線を回避できます。
生成されたテスト ハーネスは独自のスケジュール エディターを取得します。これにより、テスト ハーネスを介してイベントを簡単に送信できます。テスト ハーネス スケジューラを介して、特定の時間にイベントをトリガーしてさまざまなシナリオでモデルをテストできます。
[イベント] パネルでは、既存のイベントを他の非周期的分割にバインドすることもできます。これを行うには、イベントを有効な非周期的分割にドラッグ アンド ドロップするか、ドロップダウンを使用して分割を直接追加します。[順序] テーブルの [トリガー] としてイベントを持つ分割を他の分割と比較して順序付けることができます。スケジュール エディターでイベントを作成することもできます。プラス アイコンをクリックします。[行の追加] をダブルクリックして新しいイベントを作成します。このイベントを使用して Stateflow から送信し、非周期的分割の実行をスケジュールできます。
スケジュール エディターのイベントは、エクスポート関数をもつモデルでは使用できません。
イベントはコード生成をサポートせず、生成されたコードに影響しません。
スケジュール エディターのイベントは次のガイドラインを使用します。
イベントが処理される前にイベントは発生できません。
2 つのモデル参照に同じ名前を付けることで生じる親モデルの重複イベント名は使用できません。
無限ループは許可されません。
分割では、それ自体をトリガーするイベントを発生させることはできません。