時間オートマトンプロセスモデルとして性能検証する
タスクの状態遷移には大きく分けて2通りのパターンがあります。ひとつは、いつ遷移するのかが明確な場合です。典型的な例として、タスクが別のタスクやハードウェアに対してシグナルやメッセージを送信したことによる状態遷移があります。シグナルやメッセージの受信を待つことでタスクの中で状態が変わるといった場合もこのパターンに含まれます。これはハードウェアも同じで、処理を開始するためのレジスタに値が書き込まれることや、処理が終了して割り込みが発生することなどにより、状態が変わります。この状態遷移のパターンは遷移タイミングも限定的かつ明確なのでモデル化は比較的容易です。
もうひとつは、タスクが何らかの処理中に割り込みや他のタスク優先度の高いタスクが実行可能状態となった際、強制的にディスパッチされて状態が変わるパターンです。これは前章で紹介した通り、あらゆる状態で突発的に発生し得るためモデル化（オートマトンで表現すること）が困難です。UPPAALでもモデル化は一応可能ですが、非常に複雑なモデルとなりそうです。
上記2通りのタスク状態遷移のうち、前者の状態遷移はオートマトンで表現し、後者の状態遷移はオートマトンで表現せずにシミュレータ側で吸収する手法を提案します。これにより、モデル作成者は複雑な状態遷移を意識することなく、ハードウェアと同様にソフトウェアタスクをモデル化できます。
次節はこの提案手法の実証実験を行うため、筆者がトップエスイープロジェクトの修了制作で開発したツールについて簡単に紹介します。
シミュレータとモデル作成支援機能を持つ「P3S」について
P3S（Parallel Process Performance Simulator）はPython 3で開発した、シミュレータ兼モデル作成補助機能を備えたライブラリです。ソフトウェアタスクやハードウェアを同じレベルのプロセスモデルとして作成するためのテンプレートとなるクラスを備えています。
プロセスは時間オートマトンで表現され、「複数個の状態」「状態間の遷移」を保持することが可能です。また、遷移には遷移条件や遷移にかかる時間を設定することができます。さらに、プロセス間で通信できるチャネルも備えます。これらはライブラリ内で全てクラスとして定義されており、モデルを作成するユーザは必要に応じて機能をオーバーライドし、モデル化していきます。
図4に時間オートマトンとP3Sのモデルコードにおける遷移のテンプレートとなるTransクラスを示します。
「guard」は遷移条件を満たすかどうかを判定する機能、「sync」は同期処理機能、「get_delay」は遷移にかかる時間を取得する機能、「update」は遷移後に更新する機能です。なお、オートマトンの同期処理におけるチャネルのクエスチョンマークはシグナルの受信を表し、エクスクラメーションマークはシグナルの送信を表しています。
また、ハードウェアのプロセスモデルとソフトウェアのプロセスモデルはサブクラスで区別されており、ソフトウェアのプロセスモデルはタスク優先度やタスク状態等をパラメータとして持ちます。
ライブラリのシミュレータ部では作成したソフトウェアタスクモデルとハードウェアモデルを逐次動かしながらシミュレーションします。
ソフトウェアタスクモデルを保持するCPU（シングルコアを想定）のモデルが、単位時間ごとにタスクの優先度とタスク状態に応じて1つのソフトウェアタスクモデルを動かします。特徴として、あるソフトウェアタスクモデルの状態遷移中であっても、別の優先度の高いソフトウェアタスクモデルやISR（割り込みハンドラのことで全てのタスクよりも優先されます）モデルに処理が移る（コンテキストスイッチが発生する）こともあります。また、シミュレータ部では、コンテキストスイッチにも設定した遅延が発生するようになっているため、オーバーヘッドの遅延時間も考慮してシミュレーションすることができます。
