スケジュールエディターのイベント

イベントはアクション、遷移、または条件を表す構造です。モデルの階層構造内からイベントをブロードキャストできます。イベントは、重要な条件を検出するブロックを分割に接続して、条件が発生したときの分割の実行をスケジュールできます。スケジュールエディターでは、分割を作成および管理して、モデルの実行をスケジュールすることができます。イベントを非周期的分割にバインドし、イベントがブロードキャストされたときの実行について、優先順位に基づいてスケジュールできます。R2020b 以降、スケジュールエディターのイベントを send キーワードを使用して Stateflow^® チャートから送信できるようになりました。イベントによってシステムの作成が簡略化され、スケジュール時の柔軟性が向上します。

スケジュールエディターでのイベント管理

スケジュールエディターでは、モデルの階層構造内のモデルごとに独自の [イベント] パネルがあり、モデルとモデルの子に含まれているすべてのイベントが示されます。スケジュールエディターを開いてブロック線図を更新すると、モデル内のすべての分割とイベントがスケジュールエディターに表示されます。[イベント] パネルでは、以下を実行できます。

イベントを作成する。
イベントを削除する。
イベントの名前を変更する。
イベントを取得する。
イベントを分割にバインドする。
分割からイベントのバインドを解除する。

以下に示すように、Stateflow チャートの特定のイベントのブロードキャストに基づいて、非周期的分割の実行をスケジュールできます。

Flow chart

スケジュールエディターの [イベント] パネルには、イベントツリーが表示されます。すべてのイベントの下に、そのイベントのブロードキャスターとリスナーが表示されます。

イベントが分割にバインドされている場合、イベント名は分割の左側と、[順序] テーブルの [トリガー] 列に表示されます。

名前付け

モデル内およびモデルの階層構造内のイベントには一意の名前が適用されます。モデルの階層構造内では、モデル名の先頭にイベント名が付加されます。たとえば、ModelName という名前のモデル参照にイベント E1 が含まれる場合、イベントはスケジュールエディターに ModelName.E1 として表示されます。

イベントによる非周期的分割の実行

イベントのバインド- イベントと分割をバインドして、イベントがブロードキャストされるときに分割の実行を示すことができます。分割は単一のイベントにのみバインドできます。

優先順位に基づいた実行- イベントにバインドされた分割が、イベントを駆動する分割の前に実行されるようにスケジュールされている場合、イベントにバインドされた分割の実行は、イベントを駆動する分割の実行をプリエンプトします。トリガーされた分割の実行が、イベントを駆動する分割の後にスケジュールされている場合、トリガーされた分割は、スケジューラが実行順序で該当の位置に到達すると実行されます。

listenerPartition は非周期的分割であり、イベント Event1 に対するリスナーです。Event1 はモデル内にある Stateflow チャートから取得され、broadcastPartition という名前の分割の一部であると仮定します。broadcastPartition の実行が開始されると、Event1 が発生し、その後 listenerPartition の実行がトリガーされます。

A flowchart explaining the first paragraph of this section

ヒット時間- 指定されたヒット時間に非周期的分割をトリガーできます。分割にヒット時間があり、分割がイベントにバインドされている場合、ヒット時間は指定されたイベントに置き換えられます。同様に、分割がイベントにバインドされ、ヒット時間が追加されている場合、バインドされたイベントが分割から削除されます。変数で、非周期的分割のヒット時間も指定できます。あいまいな変数とイベント名の場合、イベントが優先されます。

イベントを使用した分割のスケジュール

ライブスクリプトを開く

この例では、イベントを使用して 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 つのモデル参照に同じ名前を付けることで生じる親モデルの重複イベント名は使用できません。
無限ループは許可されません。
分割では、それ自体をトリガーするイベントを発生させることはできません。

参考

スケジュールエディター