ドキュメンテーション

最新のリリースでは、このページがまだ翻訳されていません。 このページの最新版は英語でご覧になれます。

実行時の Stateflow オブジェクトの相互作用

実行時、Stateflow® オブジェクトは相互に作用して実世界での動作をシミュレートします。次のモデルでは、さまざまな Stateflow オブジェクトを示し、その相互作用を説明します。

例示モデルの概要

このモデル例は、チャート内のグラフィカル オブジェクトと非グラフィカル オブジェクトが実行時にどのように相互作用するかを示しています。以下のオブジェクトがあります。

  • 条件と条件アクション

  • 排他的 (OR) ステート

  • フロー チャート

  • 関数の呼び出し

  • ヒストリ ジャンクション

  • パラレル (AND) ステート

  • ステート アクション

  • 入力イベントにガードされた遷移

チャートのセマンティクスの詳細は、チャートの実行フェーズ を参照してください。

ホテルへのチェックイン プロセスのモデル

この例では、ホテルへのチェックイン プロセスを使用して Stateflow チャートのセマンティクスを説明します。

sf_semantics_hotel_checkin モデルは、4 つの Manual Switch ブロック、1 つの Mux ブロック、1 つの Multiport Switch ブロック、Hotel チャート、および Display ブロックで構成されています。

使用されるブロック目的理由

Manual Switch

シミュレーション中に一時停止や再開をすることなく 2 つの設定の間を切り替えられるようにします。

シミュレーション中に、以下の入力イベントのいずれかを送信することでチャートを対話的にトリガーできます。

  • ホテルへのチェック イン

  • ルーム サービスの呼び出し

  • 火災警報器の作動

  • 火災警報器が作動した後の警報解除信号の送信

Mux

複数の入力信号を組み合わせてベクトルにします。

チャートで複数の入力イベントを使用できるのは、それらの入力イベントがチャートのトリガー端子に入力のベクトルとして接続されている場合に限ります。

Multiport Switch

2 つ以上の入力の間で選択できるようにします。

このブロックにより、チャート入力データ room_type の値が提供されます。ここで、部屋の各タイプは数字 (1、2、または 3) に対応します。

Manual Switch ブロックで 2 つを超える入力をサポートすることはできませんが、Multiport Switch ブロックでは可能です。

Display

入力信号の最新の数値を表示します。

シミュレーション中は、チャートの出力データ fee に加えたすべての変更が表示されます。

Hotel チャートには、ステートやヒストリ ジャンクションなどのグラフィカル オブジェクトと、条件や条件アクションなどの非グラフィカル オブジェクトが含まれています。

オブジェクトをチャート内の位置にマッピングする方法については、Stateflow オブジェクトを参照してください。

チャートと Simulink ブロックとの相互作用の仕組み

チャートの初期化

シミュレーションが始まると、[初期化時に指定されたチャートを実行 (入力)] オプションがオンになっているため (チャートの初期化実行 を参照)、チャートが起動し、デフォルト遷移が実行されます。その後、チャートはスリープ状態に移行します。

メモ

このオプションがオフになっている場合、Manual Switch ブロックのいずれかを切り替えるまでチャートは起動しません。このオプションの設定は、[チャート] プロパティ ダイアログ ボックスで確認できます。チャートの最上位レベルを右クリックし、コンテキスト メニューから [プロパティ] を選択します。

チャートと他のブロックとの相互作用

以下のエッジ トリガー入力イベントが発生した場合のみ、チャートは再び起動します。check_inroom_servicefire_alarm、または all_clear です。シミュレーション中に入力イベントに対して Manual Switch ブロックを切り替えると、立ち上がりエッジまたは立ち下がりエッジが検出され、チャートが起動します。チャートが起動している間は、以下のようになります。

  • Multiport Switch ブロックにより、チャート入力データ room_type に値が与えられます。

  • Display ブロックにより、チャート出力データ fee の値の変更が示されます。

チャートの非アクティブ

可能性のある実行フェーズがすべて完了すると、チャートはスリープ状態に戻ります。

チャートの実行フェーズ

次の節では、Hotel チャートの影付きの各領域に対するチャートの実行を説明します。

ヒント

影付きの領域をクリックすると、チャートの実行フェーズに関する情報に直接ジャンプします。

フェーズ: チャートの初期化

この節では、チャートの起動直後に Front_desk ステートで何が起こるのかを説明します。

ステージホテルのシナリオチャートの動作
1

最初に、ホテルのフロント デスクで立ち止まります。

チャート レベルで、Check_in へのデフォルト遷移が発生し、このステートがアクティブになります。次に、Front_desk へのデフォルト遷移が発生し、このステートがアクティブになります。

チャートまたはステートに入るを参照してください。

2

ホテルにチェック インした後、フロント デスクから立ち去ります。

check_in イベントにより、Front_desk からの出力遷移がガードされます。check_in に対するイベント ブロードキャストがチャートに受信されると、遷移は有効になります。

チャートによるイベントの処理方法 を参照してください。

3

フロント デスクから立ち去る直前、部屋へ運ぶ荷物を手に取ります。

遷移の発生直前、Front_deskexit アクションにより、move_bags ローカル データが 1 に設定されます。次に、Front_desk が非アクティブになります。

ステートを出るを参照してください。

チャートの初期化に関するモデリング ガイドライン-  以下のガイドラインはチャート初期化に適用されます。

モデリング ガイドラインこのガイドラインが適用される理由参照

階層内の同じレベルに位置する複数のステートが同時にアクティブになることが不可能な場合は、排他的 (OR) 構造を使用します。

このガイドラインを守ることで、チャートは適切に実行されます。たとえば、ホテルの中と外に同時にいることはできないため、Check_inWaiting_area は排他的 (OR) ステートです。

デフォルト遷移を使用して、排他的 (OR) ステートのうち最初にアクティブになるものにマークを付けます。

このガイドラインを守ることで、チャートの実行中にステートの不整合エラーが起こらないようにします。

固有の数値のない発生に依存する遷移をガードするには、条件ではなくイベントを使用します。

ホテルへのチェック インの数値を定量化することはできないため、このような発生はイベントとしてモデリングします。

ステートが非アクティブになる直前に、exit アクションを使用してステートメントを 1 回実行します。

他のタイプのステート アクションは、異なる方法で実行されるため、当てはまりません。

  • Entry アクションは、ステートがアクティブになった直後に 1 回実行されます。

  • During アクションは、タイム ステップのたびに実行されます (ステートがアクティブになった後の最初のタイム ステップ以外)。チャートがそのステートにとどまり、有効な出力遷移が存在しない限り、実行は続けられます。

  • On event_name アクションは、イベント ブロードキャストが受信された後にのみ実行されます。

フェーズ: 単一のジャンクションからの複数の出力遷移の評価

この節では、Front_desk ステートから出た後に何が起こるのかを説明します。それは、単一のジャンクションからの複数の出力遷移の評価です。

ステージホテルのシナリオチャートの動作
1

部屋のタイプは 3 つあり、そのいずれかに移動できます。

check_in イベントによって Front_desk からの遷移がトリガーされた後、Multiport Switch ブロックで選択した部屋のタイプに基づいて、3 つの遷移パスが使用可能になります。各パスに割り当てた優先順位に基づいて、遷移がテストされます。

一連のフロー チャートの実行順序 を参照してください。

2

エグゼクティブ スイートを選択した場合、基本料金は 1500 です。

room_type 入力データが 1 に等しい場合は、最上位の遷移が有効です。この条件が真の場合、fee 出力データを 1500 に設定することによって条件アクションが実行されます。

メモ

最上位の遷移が有効でない場合は、次の遷移をテストするために、セントラル ジャンクションへの制御フローのバックトラッキングが発生します。この種のバックトラッキングは意図的です。

意図しないバックトラッキングとこれを回避する方法の詳細は、フロー チャートのバックトラックフロー チャート作成のベスト プラクティス を参照してください。

3

ファミリ スイートを選択した場合、基本料金は 1000 です。

room_type が 2 に等しい場合は、中間の遷移が有効です。この条件が真の場合、fee を 1000 に設定することによって条件アクションが実行されます。

4

シングル ルームを選択した場合、基本料金は 500 です。

room_type が 3 に等しい場合は、一番下の遷移が有効です。この条件が真の場合、fee を 500 に設定することによって条件アクションが実行されます。

 room_type の値が 1、2、3 のいずれでもない場合

出力遷移の評価に関するモデリング ガイドライン-  以下のガイドラインは遷移構文に適用されます。

モデリング ガイドラインこのガイドラインが適用される理由参照

数値のない発生に依存する遷移をガードするには、イベントではなく条件を使用します。

ホテルの部屋のタイプは数値的に定量化できるため、部屋のタイプの選択は条件として表現します。

Stateflow におけるフロー チャート

可能な限り、遷移アクションではなく条件アクションを使用します。

条件アクションは、条件が真であると評価されるとすぐに実行されます。遷移アクションは、終端ジャンクションまたはステートまでの遷移パスが完了するまで実行されません。

実行遅延が必要でない場合は、遷移アクションではなく条件アクションを使用します。

遷移アクション タイプ

複数の出力遷移のテスト順を管理するには、明示的な順序付けを使用します。

遷移の順序付けには、明示的な順序付けまたは暗黙的な順序付けを指定できます。既定の設定では、明示的な順序付けが使用されます。暗黙的な順序付けに切り替えた場合は、グラフィカル オブジェクトが動いたときに遷移のテスト順が変わる場合があります。

遷移の評価順序

フェーズ:スーパーステートに対するステート アクションの実行

この節では、Checked_in ステートに入った後に、どのサブステートがアクティブになるかに関係なく起こることを説明します。

ステージホテルのシナリオチャートの動作
1

目的の部屋に着いたら、運んできた荷物を置きます。

move_bags ローカル データを 0 に設定することにより、entry アクションが実行されます。

2

ルーム サービスを注文すると、ホテルからの請求額が一定額増えます。

room_service に対するイベント ブロードキャストがチャートに受信されると、以下のことが行われます。

  1. service ローカル データのカウンターが 1 だけインクリメントします。

  2. expenses への関数呼び出しが発生し、fee 出力データに保存されていた、ホテルからの請求額が返されます。

チャートによるイベントの処理方法 を参照してください。

ステート アクションの実行に関するモデリング ガイドライン-  以下のガイドラインはステート アクションに適用されます。

モデリング ガイドラインこのガイドラインが適用される理由参照

ステートがアクティブになった直後に、entry アクションを使用してステートメントを 1 回実行します。

他のタイプのステート アクションは、異なる方法で実行されるため、当てはまりません。

  • During アクションは、そのステートからの有効な遷移が現れるまで、各タイム ステップで実行されます。

  • Exit アクションは、ステートが非アクティブになる直前に 1 回実行されます。

ステート アクション タイプ

On event_name アクションまたは On message_name アクションは、イベント ブロードキャストまたはメッセージが受信された後にのみ、ステートメントを実行するために使用します。

スーパーステートを使用して、同じステート アクションを共有する複数のサブステートを囲みます。

このガイドラインを守ることで、複数のサブステートに適用されるステート アクションを再利用できるようにします。ステート アクションは、サブステートごとに記述するのではなく、1 回だけ記述します。

サブステートとスーパーステートの作成

フェーズ: ステート アクションからの関数呼び出し

チャートのこの部分では、ステートがアクティブなときに関数呼び出しを実行する方法を説明します。

ステージホテルのシナリオチャートの動作
1

部屋のタイプとルーム サービスの合計注文回数に基づいて、ホテルからの請求額を追跡できます。

expenses は、ルーム サービスの合計注文回数を入力として受け取り、現在のホテルの請求額を出力として返す MATLAB® 関数です。

関数ボックスをダブルクリックすると、以下のスクリプトが関数エディターに表示されます。

function y = expenses(x)

if (room_type == 1)
   y = 1500 + (x*50);
else
   if (room_type == 2)
      y = 1000 + (x*25);
   else
      y = 500 + (x*5);
   end
end

関数呼び出しに関するモデリング ガイドライン-  以下のガイドラインは関数呼び出しに適用されます。

モデリング ガイドラインこのガイドラインが適用される理由参照

チャートでの数値計算の実行には MATLAB 関数を使用します。

MATLAB 関数は、グラフィカル関数や真理値表、Simulink® 関数よりも、数値計算の処理に優れています。

MATLAB 関数の定義による MATLAB コードの再利用

関数シグネチャでは説明的な名前を使用します。

説明的な関数名を使用すると、チャート オブジェクトがわかりやすくなります。

フェーズ: 排他的サブステートをもつステートの実行

チャートのこの部分では、排他的 (OR) 構造が設定されたステートの実行方法を説明します。

ステージホテルのシナリオチャートの動作
1

エグゼクティブ スイートに着いたら、まずベッドルームに入ります。

メモ

エグゼクティブ スイートは、ベッドルームとダイニング エリアに分かれています。したがって、スイート ルームの複数のエリアに同時にいることはできません。

条件 room_type == 1 が真の場合は、条件アクション fee = 1500 が実行されます。その遷移パスが完了すると、以下のステートの初期化アクションがトリガーされます。

  1. Checked_in がアクティブになり、その entry アクションが実行されます。

  2. Executive_suite がアクティブになります。

  3. Bedroom へのデフォルト遷移が発生し、このステートがアクティブになります。

チャートまたはステートに入るを参照してください。

2

ルーム サービスを注文したら、ダイニング エリアに入って食事をします。

room_service イベントが発生すると、Bedroom から Dining_area への遷移が発生します。

3

ダイニング エリアでとった食事の後片付けをしてほしい場合は、再びルーム サービスを注文し、ベッドルームに戻ります。

room_service イベントが発生すると、Dining_area から Bedroom への遷移が発生します。

4

火災警報器が作動したためにエグゼクティブ スイートを出た場合は、警報解除信号が出された後、もといた部屋へ戻ります。

Executive_suite からの遷移が発生した場合、最後にアクティブであったサブステート、つまり Bedroom または Dining_area がヒストリ ジャンクションに記録されます。この遷移が発生する仕組みの詳細は、フェーズ: イベントによるステート間の遷移のガード を参照してください。

排他的 (OR) ステートの実行に関するモデリング ガイドライン-  以下のガイドラインは排他的 (OR) ステートに適用されます。

モデリング ガイドラインこのガイドラインが適用される理由参照

階層内の同じレベルに位置する複数のステートが同時にアクティブになることが不可能な場合は、排他的 (OR) 構造を使用します。

このガイドラインを守ることで、チャートは適切に実行されます。たとえば、ベッドルームとダイニング エリアに同時にいることはできないため、BedroomDining_area は排他的 (OR) ステートです。

前にアクティブであったサブステートに依存する排他的 (OR) 構造が設定されたステートに再度入る場合は、ヒストリ ジャンクションを使用します。この種のジャンクションでは、ステートから出るときにアクティブなサブステートが記録されます。

前にアクティブであったサブステートを記録しない場合はデフォルト遷移が発生し、そのステートに再度入るときに、不適切なサブステートがアクティブになる場合があります。

たとえば、食事中に火災警報が鳴ったため部屋を出た後、戻ってくる場合、ダイニング エリアではなくベッドルームに入ってしまいます。

フェーズ: パラレル サブステートをもつステートの実行

チャートのこの部分では、パラレル (AND) 構造が設定されたステートの実行方法を説明します。

ステージホテルのシナリオチャートの動作
1

家族でスイート ルームに着いた場合は、両方のベッドルームに家族がいることが可能です (たとえば、両親がマスター ベッドルームにいて子供たちがセカンド ベッドルームにいるなど)。既定の部屋選択は適用されません。

条件 room_type == 2 が真の場合は、条件アクション fee = 1000 が実行されます。その遷移パスが完了すると、以下のステートの初期化アクションがトリガーされます。

  1. Checked_in がアクティブになり、その entry アクションが実行されます。

  2. Family_suite がアクティブになります。

  3. パラレル ステートは、各ステートの右上隅に表示された番号順に起動します。まず Master_bedroom、次に Second_bedroom です。

     順序の指定方法

チャートまたはステートに入るを参照してください。

2

両方の部屋を同時に使用することができます。

Master_bedroomSecond_bedroom が同時にアクティブなステートに保たれます。

パラレル (AND) ステートの実行に関するモデリング ガイドライン-  以下のガイドラインはパラレル (AND) ステートに適用されます。

モデリング ガイドラインこのガイドラインが適用される理由参照

階層内の同じレベルに位置するすべてのステートが同時にアクティブになることが可能な場合は、パラレル (AND) 構造を使用します。

このガイドラインを守ることで、チャートは適切に実行されます。たとえば、マスター ベッドルームとセカンド ベッドルームは同時に使用することができるため、Master_bedroomSecond_bedroom はパラレル ステートです。

パラレル (AND) 構造の設定されたステートでは、ヒストリ ジャンクションを使用しません

このガイドラインを守ることで、解析エラーが起こらないようにします。階層内の同じレベルに位置するすべてのパラレル ステートが同時にアクティブであるため、ヒストリ ジャンクションを使用する意味がありません。

パラレル (AND) ステートの実行順序の管理には、明示的な順序付けを使用します。

パラレル ステートの順序付けには、明示的な順序付けまたは暗黙的な順序付けを指定できます。既定の設定では、明示的な順序付けが使用されます。暗黙的な順序付けに切り替えた場合は、パラレル ステートが動いたときに実行順序が変わる場合があります。

フェーズ: イベントによるステート間の遷移のガード

チャートのこの部分では、イベントによる排他的 (OR) ステート間の遷移のガード方法を説明します。

ステージホテルのシナリオチャートの動作
1

火災警報が鳴ったら、ホテルを出て、外の待ち合い場所に移動します。

fire_alarm に対するイベント ブロードキャストがチャートに受信されると、Check_in のサブステートから Waiting_area への遷移が発生します。

 この遷移が発生する仕組み

2

警報解除信号が出されると、待ち合い場所を離れてホテル内のもといた場所に戻ることができます。

all_clear に対するイベント ブロードキャストがチャートに受信されると、Waiting_area から Check_in の最後にアクティブであったサブステートへの遷移が発生します。

Check_in の各階層レベルのヒストリ ジャンクションにより、どのサブステートが Waiting_area への遷移の発生前にアクティブであったかがわかります。

 この遷移が発生する仕組み

遷移のガードに関するガイドラインのモデル化-  以下のガイドラインではイベントに対する条件の使用法を検討します。

モデリング ガイドラインこのガイドラインが適用される理由参照

数値のない発生に依存する遷移をガードするには、条件ではなくイベントを使用します。

火災警報や警報解除信号の数値を簡単に定量化することはできないため、このような発生はイベントとしてモデリングします。

入力イベントの送信による Stateflow チャートのアクティブ化