Main Content

このページの内容は最新ではありません。最新版の英語を参照するには、ここをクリックします。

Rate Transitions ブロックと Asynchronous ブロック

非同期の Function-Call Subsystem は他のモデル コードをプリエンプトしたり、プリエンプトされたりするため、1 つを超える信号要素が非同期のブロックに接続されている場合、不一致が生じます。このため、Function-Call Subsystem に入出力される信号は、プリエンプションが発生したときに書き込みまたは読み取り中である場合があります。このように、一部が古く、一部が新しいデータが使用されます。この状況は、スカラー信号でも発生する場合があります。たとえば、信号が倍精度 (8 バイト) の場合、読み取りまたは書き込み操作で 2 つのマシンの指示が必要となる場合があります。

メモ

このトピックに示されているオペレーティング システムの統合手法では、Interrupt Templates ブロック ライブラリのブロックを使用します。そのライブラリのブロックは、特定のターゲット環境でカスタム ブロックを開発するのに役立つ例となります。

Rate Transitions ブロックと Asynchronous ブロックについて

Simulink® Rate Transition ブロックは、異なるレートで実行中のブロック間のデータ転送時に発生するプリエンプションの問題を処理するように設計されています。これらの問題は、時間ベースのスケジューリングとコード生成で説明します。

レート変換の問題は、モデル コンフィギュレーション パラメーター [データ転送に対するレート変換を自動的に取り扱う] を選択することにより、自動的に処理できます。こうすることにより、Rate Transition ブロックを手動で挿入しなくても、マルチレート モデルにおける無効なレート変換 ("非同期から周期" のレート変換や "非同期間" のレート変換) を防ぐことができます。非同期タスクの場合、Simulink エンジンでは、挿入されるブロックがデータ転送時のデータの整合性をとるように設定されますが、確定性をもつようには設定されません。

非同期のレート変換の場合、Rate Transition ブロックによって、データの整合性はとれますが、確定性をもたせることはできません。したがって、Rate Transition ブロックを明示的に挿入した場合、ブロック パラメーター [確定的にデータ転送を確保 (最大遅延)] をオフにしなければなりません。

2 つのブロック間に Rate Transition ブロックを挿入してデータの整合性をとる場合に、ブロックに関連付けられているタスクに優先度が割り当てられている場合、コード ジェネレーターでは、優先度の高いタスクが優先度の低いタスクをプリエンプトでき、優先度の低いタスクは優先度の高いタスクをプリエンプトできないことを想定しています。いずれかのブロックのタスクに関連付けられている優先度が割り当てられず、両方のブロックのタスクの優先度が同じ場合、コード ジェネレーターでは、いずれかのタスクが一方のタスクをプリエンプトできると想定します。

周期的タスクの優先順位は、[コンフィギュレーション パラメーター] ダイアログ ボックスの [ソルバー] ペインの [ソルバーの選択] セクションで指定されたパラメーターに従って、Simulink エンジンによって割り当てられます。[周期的なサンプル時間の制約] パラメーターが [制約なし] に設定されている場合、モデルの基本レートの優先順位は 40 に設定されます。サブレートの優先順位は、パラメーター [優先順位の値が高いほどタスクの優先順位が高いことを示す] の設定に応じて、基本レートの優先順位から 1 ずつ増加または減少します。

優先順位を手動で割り当てるには、パラメーター [Periodic sample time properties] を使用します。Simulink エンジンは、非同期のブロックに優先度を割り当てません。たとえば、Async Interrupt ブロックに接続される Function-Call Subsystem の優先順位は、Async Interrupt ブロックによって割り当てられます。

Async Interrupt ブロックのブロック パラメーター [Simulink タスクの優先順位] は、パラメーター [VME 割り込み番号] に入力された各割り込み数の (必要な) 優先順位レベルを指定します。この優先度配列によって、各割り込みに接続されたサブシステムの優先度が設定されます。

Task Sync ブロックでは、RTOS 例 (VxWorks®) がターゲットの場合、ブロック パラメーター [優先順位の値が高いほどタスクの優先順位が高いことを示す] をオフにします。パラメーター [Simulink タスクの優先順位] で、接続されたブロックに関連するブロックの優先順位が指定されます (また、生成されたタスク コードに RTOS 優先順位が割り当てられます)。

vxlib1 ライブラリは、2 種類のレート変換ブロックを使用できるため便利です。この 2 つのブロックは、Rate Transition ブロックの事前に構成されたインスタンスです。

  • Protected Rate Transition ブロック: ブロック パラメーター [データ転送中の整合性を確保] が選択され、[確定的にデータ転送を確保] がオフに設定された Rate Transition ブロック。

  • Unprotected Rate Transition ブロック:[データ転送中の整合性を確保] がオフに設定された Rate Transition ブロック。

非同期タスクのレート変換の処理

非同期タスクに関係するレート変換の場合、データの整合性を維持できます。ただし、確定性は達成できません。Rate Transition ブロックを使用するか、ターゲット固有のレート変換ブロックを使用するかを選択します。

以下のモデルでは Rate Transition ブロックを使用します。

Model that includes a Rate Transition block

次のモードのいずれかで Rate Transition ブロックを使用します。

  • データの整合性を保持、確定性なし

  • 非保護

または、ターゲット固有のレート変換ブロックを使用します。RTOS 例 (VxWorks) では次のブロックを使用できます。

  • Protected Rate Transition ブロック (リーダー)

  • Protected Rate Transition ブロック (ライター)

  • Unprotected Rate Transition ブロック

複数の非同期割り込みの処理

次のモデルでは、2 つの関数によって同じサブシステムがトリガーされます。

Model that includes two functions that trigger the same subsystem

この 2 つのタスクの優先度は同じです。優先度が同じ場合、結果はこれらのタスクが周期的に開始するか、非同期的に開始するか、および診断設定によって異なります。次の表とメモで、これらの結果について説明します。

複数のトリガーをもつ Function-Call Subsystem のサンプル時間と優先度のサポート

 

Async Priority = 1

Async Priority = 2

Async Priority Unspecified

Periodic Priority = 1

Periodic Priority = 2

Async Priority = 1

サポートあり (1)

    

Async Priority = 2

 

サポートあり (1)

   

Async Priority Unspecified

  

サポートあり (2)

  

Periodic Priority = 1

   

サポートあり

 

Periodic Priority = 2

    

サポートあり

  1. これらの結果はモデル コンフィギュレーション パラメーター [同じ優先順位をもつタスク] を使用して制御します。この診断は、同じ優先順位のタスクがターゲット システムでお互いにプリエンプトできない場合、[なし] に設定します。

  2. この場合、次の警告メッセージが無条件で発行されます。

    The function call subsystem <name> has multiple asynchronous 
    triggers that do not specify priority. Data integrity will 
    not be maintained if these triggers can preempt one another.

上の表の空のセルは、優先度が異なる複数のトリガーを表し、サポートされていません。

コード ジェネレーターでは、TriggerATriggerB のタイマーの設定 (時間ソース、分解能) が同じ場合、複数の割り込みに接続された Function-Call Subsystem の絶対時間の管理が可能です。

次の条件のすべてが上記のモデルで真であるとします。

  • Function-Call Subsystem は、優先度の設定が同じ 2 つの非同期のトリガー (TriggerA および TriggerB) によってトリガーされます。

  • 各トリガーは、関数 ssSetTimeSource および関数 ssSetAsyncTimerAttributes を呼び出して、時間およびタイマーの属性のソースを設定します。

  • トリガーされたサブシステムには、経過時間または絶対時間を必要とするブロック (Discrete Time Integrator など) が含まれています。

非同期の Function-Call Subsystem は、1 つのグローバル変数 clockTick# (# はサブシステムに関連付けられたタスク ID) をもちます。この変数は、非同期タスクの絶対時間を格納します。タイミングを処理する方法は次の 2 つです。

  • 時間のソースが SS_TIMESOURCE_BASERATE に設定される場合、コード ジェネレーターは、基本レートのクロック ティックからクロック ティック変数を更新して、Function-Call Subsystem でタイマー コードを生成します。データ整合性は、同じ優先度が TriggerA と TriggerB に割り当てられている場合、維持されます。

  • 時間のソースが SS_TIMESOURCE_SELF の場合、TriggerA および TriggerB の生成コードによって、同じクロック ティック変数がハードウェア クロックから更新されます。

クロック ティック変数のワード サイズは、直接設定することもできますが、モデル コンフィギュレーション パラメーター [アプリケーションのライフスパン (日)] の設定に従って設定されます。タイマーの分解能は、TriggerA および TriggerB の S-Function (同じでなければなりません) によって設定されます。詳細については、非同期タスクにおけるタイマーおよび時間カウンターに対するメモリの割り当ての制御を参照してください。

volatile キーワードを使用したデータの整合性の保護

ブロック パラメーター [データ転送中の整合性を確保] を選択すると、Rate Transition ブロックに対して生成されたコードでは、volatile のグローバルなバッファーとセマフォを定義し、それらを使用して転送されるデータの整合性を保護します。保護を強化する場合や Rate Transition ブロックを使用せずに保護する場合は、volatile を転送されたデータに明示的に適用できます。詳細については、型修飾子 const と volatile を使用したグローバル データの保護 (Embedded Coder)を参照してください。

関連するトピック