特集●ソフトウェア論文
トレースログ可視化ツール
TraceLogVisualizer (TLV)
後藤 隼弐 本田 晋也 長尾 卓哉 高田 広章
マルチプロセッサ環境で動作するソフトウェアのデバッグには，トレースログの解析が有効であるが，開発者がト レースログを直接扱うのは非効率的である．そのため，トレースログを可視化することにより解析を支援するツール が存在するが，これらは汎用性や拡張性に乏しいという問題がある．そこで我々は，これらの問題を解決したトレー スログ可視化ツール (TLV) を開発した．TLV は，変換ルールによりトレースログを標準形式に変換することで汎 用性を実現し，可視化ルールにより可視化表示項目の追加・変更を可能にすることで拡張性を実現している．TLV を用いて形式の異なる 3 種類のトレースログを可視化し，汎用性と拡張性を確認した．It is effective to debug software executed in multi processors by analyzing a trace log, but it is inefficient that developers analyze the trace log directly. Therefore, some visualization tools for the trace log had been developed before now, but there are two problems, lacks of general versatility and expandability. To that end, we developed TraceLogVisualizer(TLV), a visualization tool for the trace log that solved those problems. In this paper, we will discuss requirements to achieve general versatility and expandability, and how we achieved them.
1 はじめに
近年，組込みシステムにおいても，マルチプロセッ サの利用が進んでいる．その背景には，シングルプロ セッサの高クロック化による性能向上効果の限界や， 消費電力の増大がある．マルチプロセッサシステムで は，処理の並列性を高めることにより性能向上を実 現するため，消費電力の増加を抑えることができる．Visualization Tool for Trace Log: TraceLogVisualizer (TLV).
Junji Goto, 名古屋大学大学院情報科学研究科．現在 ソ ニ ー 株 式 会 社, Graduate School of Information Science, Nagoya University. Presently with Sony Corporation.
Hiroaki Takada, 名 古 屋 大 学 大 学 院 情 報 科 学 研 究 科, Graduate School of Information Science, Nagoya University.
Shinya Honda, Takuya Nagao, 名古屋大学大学院情報科 学研究科附属組込みシステム研究センター, Center for Embedded Computing Systems, Graduate School of Information Science, Nagoya University
コンピュータソフトウェア, Vol.27, No.4 (2010), pp.8–23. [ソフトウェア論文] 2009 年 11 月 13 日受付. しかし，マルチプロセッサ環境で動作するソフトウェ アのデバッグを行うのは，シングルプロセッサ環境に 比べ困難であるという問題がある．これは，各プロ セッサが非同期的に並列動作するため，タイミングに 依存した再現性の低いバグが発生する可能性がある ことや，ハードウェアの制約からプロセッサ間の同期 精度が低い場合があり，ブレークポイントやステップ 実行を用いた従来のデバッグ手法が有効ではない場合 があるからである． 一方，マルチプロセッサ環境で有効なデバッグ手法 として，プログラム実行履歴であるトレースログを解 析する手法が挙げられる．この手法が有効である理由 は，並列プログラムのデバッグを行う際に必要な情報 である，プロセスが，いつ，どのプロセッサで，どの ように動作していたかを知ることができるからであ る．しかしながら，開発者がトレースログを直接解析 するのは効率が悪い．図1に，マルチプロセッサ対 応のRTOSである，TOPPERS/FMPカーネル(以 下，FMPカーネル)[4]が2プロセッサで動作した場 合のトレースログの例を示す．約430µsの間に5行
[time(µs)]:[core id]: information
1 [60692484]:[1]: task 4 becomes WAITING. 2 [60692586]:[2]: leave to sns_ctx state=0. 3 [60692708]:[1]: dispatch from task 4. 4 [60692798]:[2]: enter to get_pid p_prcid=304. 5 [60692914]:[1]: dispatch to task 1. 図 1 2 プロセッサ上で動作する TOPPERS/FMP カーネルが出力するトレースログの例 のトレースログが出力されており，トレースログを収 集する時間が長くなれば膨大な量になることを示唆 している．取得する情報の粒度を細かくしたり，処理 の複雑さが増すと，出力されるトレースログの量は さらに増大するため，デバッグを行う際に必要な情報 を探し出すのが困難となる．また，各プロセッサのト レースログは時系列に分散して記録されているため， プロセッサ毎の動作を解析するのが困難である． トレースログの解析を支援する方法として，ツール によるトレースログの可視化がある．並列プログラム のトレースログの可視化に関する研究として，Jave， MPI，OpenMP等の可視化に関する研究やツールが 開発されている[5] [6] [7] [8] [9] [10]．一方，RTOSを含 むOSのトレースログの可視化に関しては，組込みシ ステム向けデバッガソフトウェアや統合開発環境の一 部[12] [13] [14] [15]やUnix系OSのトレースログプロ ファイラ[17] [19]などが存在する． これらOSのトレースログの可視化のツールは，特 定の環境(OS等)を対象としているため，可視化対 象となるトレースログの形式が固定されている．その ため，FMPカーネルの様な可視化ツールが用意され ていないOSのトレースログの可視化に，これらの既 存ツールを用いることができず，汎用性に乏しいとい う問題がある．また，可視化表示する項目やその表現 方法が固定である場合が多く，拡張性に乏しいという 問題もある．例えば，OSをサポートしている可視化 ツールは，タスクやセマフォといったOSのオブジェ クトの状態を可視化することが可能であるが，OS上 で動作するアプリケーションの開発時には，これらの 情報に加えて，アプリケーションの状態(モード・進 捗状況)や重要な変数の値といったアプリケーション 固有の情報を可視化したい場合がある．可視化したい 情報やその表現方法は，アプリケーション毎に異なる ため，可視化ツールで一般的にサポートすることは困 難であり，何らかの拡張機能が必要となる． そこで我々は，これらの問題を解決し，汎用性と拡 張性を備えた，OSのトレースログの可視化を主たる 目的としたトレースログ可視化ツールを開発するこ とを目的とし，TraceLogVisualizer(TLV)を開発し た．TLVは，「OJLによる最先端技術適応能力を持つ IT人材育成拠点の形成」[2] [3]のOJL(On the Job Learning)の開発テーマとして開発し，オープンソー スソフトウェアとして公開している[1]． 開発にあたり，我々は，まず，TLV内部でトレー スログを一般的に扱えるよう，トレースログを一般化 した標準形式を定めた．さらに，任意の形式のトレー スログを標準形式に変換するためのルールを変換ルー ルとして形式化し，ユーザがツールの外部から指定で きる仕組みを提供した．次に，トレースログの可視化 表示項目やその表現方法を指示する仕組みの抽象化 を行い，可視化ルールとして形式化した．また，可視 化ルールをユーザが外部から指定できる仕組みを提 供した．これにより，TLVでは，トレースログの形 式毎に変換ルールと可視化ルールを外部ファイルとし て用意することで可視化が可能であり，汎用性と拡張 性を実現している． 本論文は次のように構成される．まず，2章で既存 のトレースログ可視化ツールとその問題点について述 べる．3章では，汎用性と拡張性を実現するためのト レースログ可視化ツールの要件と，TLVでの実現方 針について述べる．4章では，要件と実現方針に基づ くTLVの設計について述べ，5章では，その実装に ついて述べる．6章ではTLVのユーザインタフェー スについて述べ，7章では，複数のトレースログの 可視化表示や，可視化表示項目の変更，追加を行い， TLVの汎用性と拡張性を示す．最後に，8章でまと めと今後の課題，展望を述べる．
2 既存のトレースログ可視化ツールと問題点
RTOSを含むOSのトレースログを対象とした，既 存のトレースログ可視化表示ツールとその問題点に ついて述べる．また，ハードウェアや並列プログラミ ングを対象としたトレースログの形式及びそのツールのOSのトレースログの可視化への流用について述 べる． 2. 1 既存のトレースログ可視化ツール OSのトレースログを対象としたトレースログ可視 化表示ツールとしては，組込みシステム向けデバッガ ソフトウェアや統合開発環境の一部，Unix系OSの 可視化ツールなどがある．また，標準化されたトレー スログ形式としてVCD形式やPaj`e形式がある． 組込みシステム向けデバッガソフトウェアには，OS のトレースログを可視化する機能を持つものがある． PARTNER[12]はイベントトラッカー，WatchPoint [13]はOSアナライザというOSのトレースログを可 視化する機能を提供している．また，組込みOS向 けの統合開発環境にもOSのトレースログを可視化 するツールが含まれている．QNX用の統合開発環境 であるQNX MomenticsにはQNX System Profiler [14]が，T-Kernel用の統合開発環境であるeBinder [15]にはEvenTrekが付属しており，システムコール， タスクスイッチ，タスク状態遷移などを可視化可能で ある． Unix系OSでは，パフォーマンスチューニングや 障害解析を目的として，カーネルの実行トレースを 取得して，可視化するソフトウェアがいくつか開発さ れている．Linuxの実行トレースを取得するLTTng [16]には，LTTV[17]が，Solarisの実行トレースを取 得するDtrace[18]には，Chime[19]が可視化ツール として提供されている． デ ジ タ ル 回 路 設 計 用 論 理 シ ミュレ ー タ 用 に ， VCD(Value Change Dump)形式というオープンな トレースログの形式が存在する．VCD形式を可視化 するツールとして，GTKWaveが存在する． また，主に並列プログラム用に，Paj`e 形式という トレースログの形式が提案されている．Paj`e形式は， トレースログ中でプロセスの状態定義や可視化時に 表示する色を指定することが可能である．Paj`e形式 を可視化するツールとして，Visual Trace Explorer [11]が存在する． 2. 2 既存のトレースログ可視化ツールの問題点 1点目の問題として，扱えるトレースログの形式が 限定されていることが挙げられる．これは，既存のト レースログ可視化ツールの多くは，可視化ツールと して単体で存在しているわけではなく，開発環境やト レースログを出力するソフトウェアの一部として提供 されているためである． 一方，任意の形式のトレースログをVCD形式や Paj`e形式に変換することにより，これらのトレース ログ形式に対応した可視化ツールを利用できる．図 2に，RTOSのトレースログをVCD形式に変換し て，GTKWaveで可視化したスクリーンショットを示 す．VCD形式はデジタル回路設計用の形式であるた め，表示能力に乏しく，複雑な可視化表現は不可能で ある． 図3に，PthreadプログラムのトレースログをPaj`e 形式で生成し，Visual Trace Explorerで可視化表示 した例を示す．Paj`e形式は，VCD形式と比較する と表現能力は高いが，状態の定義と状態毎の色指定程 度の自由度しかないため，複雑な可視化表現は不可能 である． 扱うトレースログの形式を制限しないためには， 図 2 GTKWave による RTOS のトレースログの 可視化
図 3 Visual Trace Explorer による Pthread プログラムのトレースログの可視化
VCD形式やPaj`e形式のようにOSを対象としたト レースログ可視化ツール用に標準化されたトレース ログ形式を定める必要がある．しかしながら，現状， 公表されているものではそのようなものは確認でき ていない． 2点目の問題として，既存のトレースログ可視化 ツールは，可視化表示の項目や形式が，提供されてい るものに限られているということが挙げられる．可視 化表示の項目を追加，変更したり，可視化表現をカス タマイズする機能を持つOSのトレースログを対象と したツールは確認できていない．
3 要件と実現方針
本章では，トレースログ可視化ツールが汎用性と拡 張性を備えるための要件と，TLVでの実現方針につ いてそれぞれ説明する． 3. 1 要件 まず，トレースログ可視化ツールの定義，ならびに その汎用性と拡張性の要件を明確にする． トレースログ可視化ツールを，時系列に記録され たプログラムの実行履歴をテキスト形式でファイル 化したトレースログファイルを読み込み，その内容を GUIを通じて可視化表示するツールとする． 可視化表示項目とは，トレースログの内容や出力元 の環境，解析の目的などに基づき区分される可視化表 示する情報の単位である．具体的には，RTOSのト レースログの場合，“タスクの状態遷移”や“システ ムコール呼び出し”などが該当する． 汎用性は，ユーザがツールのバイナリを変更するこ となく，様々な形式のトレースログを可視化表示でき ることとする．すなわち，入力するトレースログの形 式を制限しない． 拡張性は，ユーザがツールのバイナリを変更するこ となく，容易に可視化表示項目の追加・変更・削除が できることとする． 3. 2 汎用性の実現方針 汎用性を実現するために，トレースログの標準形式 を定め，可視化表示の仕組みが標準形式にのみ依存1 [1000]enter to act_tsk tskid=1 2 [1005]task 1 becomes READY 3 [1010]dispatch to task 1. 図 4 TOPPERS/ASP カーネルのトレースログの例 するようにする．そして，任意の形式のトレースログ を，標準形式に変換するためのルールを変換ルールと して形式化し，ユーザが外部から指定できる仕組みを 提供する． トレースログ可視化ツールが汎用性を実現するた めには，可視化表示の仕組みが特定のトレースログの 形式に依存しないようにしなければならない．そのた め，様々なトレースログ形式を一般化したトレースロ グ形式を定め，トレースログ可視化ツールはこの形式 を扱うこととする．一般化したトレースログの形式を 標準形式と呼ぶ． 標準形式への変換は，逐次的なテキストの置き換 えといった，単純なテキスト処理では要件を満たせな い場合がある．例として，図4に示す，ITRON仕様 [22]のRTOSであるTOPPERS/ASPカーネル(以 下，ASPカーネル)[21]のトレースログを標準形式に 変換する場合を考える．このログは，1行目で実行状 態(RUNNING)のタスクがact tsk()というシステ ムコールで，タスクID(tskid)が1のタスクを起動す る．2行目で起動されたタスクIDが1のタスクの状 態が実行可能状態(READY)となる．次に，タスク IDが1のタスクは，実行状態のタスクより優先度が 高いため，3行目でディスパッチが発生する． 3行目には，実行状態のタスクの状態が実行可能状 態となり，代わりに，タスクIDが1のタスクの状態 が実行状態となったという情報が暗に含まれている． ASPカーネルがこのログを出力しないのは，トレー スログを出力するコストを減らすためである．一方， 標準形式のトレースログでは，可視化のために，タス ク状態の変更箇所を明確に出力する必要がある．その 際，実行状態のタスクが存在しないケースもあるた め†1，標準形式に変換する際には，この時点で実行状 態であるタスクが存在するかどうか，また，存在する †1 実行中のタスクが存在しない状態で，ハンドラからタ スクが起動された場合．
場合はどのタスクであるのか，という情報が必要とな る．そのため，これらの情報を，変換元のトレースロ グファイルの内容から判断する必要がある． このように，標準形式への変換処理においては，変 換元のトレースログが暗に含む情報を出力するため， それを出力する条件の制御，また条件を制御するため に必要な情報を取得する手段が必要である． 3. 3 拡張性の実現方針 拡張性を実現するためには，汎用的な可視化表示の 仕組みを提供し，ユーザが可視化表示項目に合わせ てそれを制御できればよい．つまり，可視化表示項目 毎に可視化表示の仕組みを用意するのではなく，汎用 的な可視化表示の仕組みに対して，可視化表示項目 を実現するパラメータを指定することで可視化表示 を行う．そして，ユーザがツールの外部からパラメー タを指定する手段を実現すればよい．その際，汎用性 の実現のため，可視化表示の仕組みは，標準形式のト レースログにのみ依存するようにしなければならな い．また，指定するパラメータは，描画処理に必要な GUIフレームワークや表示デバイスに依存しないこ とが要求される．これは，プログラムの可搬性を損な わないためである． 汎用的な可視化表示の仕組みを実現するために，ま ず，トレースログの内容から可視化表現を決定して表 示するまでの流れを抽象化し，本質的な処理を洗い 出す．次に，ユーザが，どの処理に，どのようなパラ メータを指定できればよいかを判断し，可視化ルール として形式化する．そして，ユーザがツールの外部か ら可視化ルールを指定できる仕組みを提供する．
4 設計
本章では，汎用性を実現するための標準形式と変換 ルールと，拡張性を実現するための可視化表示の仕組 みと可視化ルールの設計について説明する． 4. 1 標準形式 トレースログを一般化するため，RTOSやUnix系 OS，プロセッサシミュレータなどのトレースログの 形式の調査を行った．その結果から，次のようにト レースログを一般化した． トレースログは，時系列にイベントを記録したも のとした．イベントとはイベント発生源の事象であ り，イベント発生源の“属性の変化”，または“振る 舞い”とした．ここで，イベント発生源をリソースと 呼称し，固有の識別子として名前を持つとした．つま り，リソースとは，イベントの発生源であり，名前を 持ち，固有の属性を持つ．固有の属性としては，“属 性”と“振る舞い”があり，型により定義される．型 は，リソースタイプと呼称して固有の識別子として名 前をもつとした．属性は，リソースが固有にもつ文字 列，数値，真偽値で表されるスカラーデータとし，振 る舞いは，リソースの行為であるとする．それぞれは 固有の識別子として名前をもつ．リソースタイプは， 可視化対象の環境(OSプロセッサシミュレータなど) 毎に定義され，リソースはアプリケーション(応用) 毎に，そのアプリケーションが動作する環境で定義さ れたリソースタイプを型として定義される． 例として，RTOSが出力する，「TASK1という名前 のタスクの状態が実行状態に遷移した」という情報の トレースログを，一般化した方法で考えてみる．この 場合，TASK1がリソースであり，タスクがリソース タイプである．また，タスクの状態は属性にあたり， その属性が実行状態という値に変化したというイベ ントであると言える．また，「TASK1という名前のタ スクがセマフォを取得するシステムコールを呼び出し た」という情報のトレースログでは，“システムコー ル呼び出し”が振る舞いとなる． 図5に，一般化の結果を形式化したトレースログの 標準形式の定義を示す．定義には，EBNF(Extended Backus Naur Form)，および終端記号として正規表 現を用いている．正規表現はスラッシュ記号(/)で挟 み記述している． トレ ースロ グが記 録さ れたファイル のデー タを TraceLog，TraceLog を改行記号で区切った１行を TraceLogLineとする．TraceLogLineは“[”,“]”で時 刻を囲み，その後ろにイベント(Event)を記述する ものとする．時刻はTimeとして定義され，数値とア ルファベットで構成される．アルファベットが含まれ るのは，10進数以外の時刻を表現できるようにする1 TraceLog = { TraceLogLine,"\n" }; 2 TraceLogLine = "[",Time,"]",Event; 3 Time = /[0-9a-zA-Z]+/; 4 Event = Res,".",(AttrChange|BhvrHappen); 5 Res = ResName|ResTypeName,"(",AttrCond,")"; 6 ResName = Name; 7 ResTypeName = Name; 8 AttrCond = BoolExp; 9 BoolExp = Bool|CompExp 10 |BoolExp,[{LogclOpe,BoolExp}] 11 |"(",BoolExp,")"; 12 CompExp = AttrName,CompOpe,Value; 13 Bool = "true"|"false"; 14 LogclOpe = "&&"|"||"; 15 CompOpe = "=="|"!="|"<"|">"|"<="|">="; 16 AttrName = Name; 17 AttrChange = AttrName,"=",Value; 18 Value = /[^"\\]+/; 19 BhvrHappen = BhvrName,"(",Args,")"; 20 BhvrName = Name; 21 Args = [{Arg,[","]}]; 22 Arg = /[^"\\]*/; 23 Name = /[0-9a-zA-Z_]+/; 図 5 標準形式の定義 ためである．これは，時刻の単位として「秒」以外の もの，たとえば「実行命令数」などを表現できるよう に考慮したためである．この定義から，時刻には，2 進数から36進数までを指定できる． イベント(Event)は，リソース(Res)と，属性の 値の変化イベント(AttributeChange)もしくは，振 る舞いイベント(BehaviorHappen)をドット“.” で 繋げることで，どのリソースの属性の値の変化もしく は振る舞いのイベントが発生したかを表す． リソースの記述方法(5行目)は，リソースの名前 (ResName)による直接指定か，リソースタイプの名前 と属性の条件(ResTypeName(AttrCond))による条件 指定の2通りの方法で指定できるとした．条件指定 では，リソースタイプとリソースの属性の値から，特 定のリソース，または複数のリソースを表現するこ とができる(8∼15行目)．条件指定は，3. 2節で述べ た，変換元のトレースログが暗に含む情報の表現を可 能にするため導入した． 属性の値の変化イベント(17行目)と振る舞いのイ ベント(19行目)の記述方法は，JavaやC++などの オブジェクト指向言語における，メンバ変数への代入 と，メソッドの呼び出しの記法と同様である． 1 [1000]Task(state==RUNNING).enterSVC(act_tsk, tskid=1) 2 [1005]TASK1.state=READY 3 [1010]Task(state==RUNNING).state=READY 4 [1010]TASK1.state=RUNNING 図 6 図 4 の ASP カーネルのトレースログの 標準形式による表現 4. 1. 1 標準形式の例 図4のASPカーネルトレースログを標準形式とし た例を図6に示す†2．タスクのリソースタイプの名 前はTask，タスクIDが1のタスクはTASK1とい う名前のリソースとする． 1行目が振る舞いのイベントであり，2∼4行目が 属性の値の変化イベントである．1行目は，実行状態 のリソースがenterSVCという振る舞いを，act tsk とtskid=1を引数として発生したことを表現してい る．2∼4行目は各リソースの属性であるタスク状態 (state)の値が変化したことを表現している．2行目 と4行目はリソースを名前で直接指定している．一 方，1行目と3行目はリソースタイプの名前(Task) と属性の条件(state==RUNNING)によってリソースを 指定しており，それぞれ，その時点でリソースタイプ の名前がTaskのリソースのうち，属性のタスク状態 (state)が実行状態であるリソースを指定している． 4. 2 変換ルール 変換ルールは，任意の形式のトレースログを，標準 形式トレースログに変換するためのルールであり，こ れらの対応関係を定義したものである．具体的には， 変換対象となる変換元のトレースログを正規表現と して記述し，その正規表現にマッチした場合に標準形 式のトレースログに出力する内容を指定したルール の集合である．標準形式への変換は，変換ルールに基 づき，テキストの変換処理を行う処理である． 標準形式への変換処理に，awkなどの既存のテキ スト処理用スクリプト言語を使用する方法がある．し かしながら，3. 2節で述べたように，変換元のトレー スログが暗に含む情報を出力するために，リソースの †2 図 6 の標準形式は変換ルールによる変換結果ではな く，標準形式の説明のための人手による変換結果であ る．
属性の初期値や型などの情報を参照したり，リソース 毎に属性の値の遷移を監視する必要があるため，実用 的ではない． そこで，TLVでは，出力する条件の制御を，指定 された時刻での特定リソースの有無や数や属性の値， 属性値変更イベントであれば変更後の値を，振る舞い イベントであればその引数などを用いて論理式を記 述することで行う．論理式の記述は，それらの値を取 得できる置換マクロを用いて行い，その際の記法には 標準形式を用いる． 変換ルールを3. 2節で述べた，図4の3行目の「あ るタスクにディスパッチした」というトレースログを 標準形式に変換する例で説明する．出力したい標準形 式のトレースログは図6の3∼4行目である．4行目 はディスパッチ先のタスクを実行状態とすればよいた め，単純な置換で実現可能である．3行目は，置換マ クロを用いて，実行状態のタスクが存在するかチェッ クして，存在すれば，そのタスクの状態が実行可能状 態となったことを標準形式のトレースログとして生成 する． 4. 3 可視化表示の仕組み 3. 3節の方針に従い，トレースログの内容から可視 化表現を決定して表示するまでの流れを抽象化し，可 視化表示の仕組みとして本質的な処理を洗い出す．そ して，ユーザが，どの処理に，どのようなパラメータ を指定すればよいかを判断する． 4. 3. 1 可視化表示の抽象化 トレースログ可視化ツールにおいて，可視化表示 とは，可視化表示項目毎に要求される表現(以下，可 視化表現)を，トレースログの内容に従い時系列の図 として画面に描画する処理であると考えられる．こ こで，画面への描画は，GUIフレームワークに依存 するため，可視化表示の仕組みとしては本質的では ない．そのため，可視化表示の仕組みは，可視化表現 を，時間と高さを次元にもつ仮想的な座標に割り当 てる処理であると抽象化できる．ここで，可視化表現 は，複数の図形で構成されるものとする．図7に，抽 象的な可視化表示の仕組みを示す． 図形は，楕円や四角などの複数の基本図形で構成さ 図 7 抽象的な可視化表示の仕組み れていると考えることができる．このとき，図形を定 義する座標系をローカル座標系と呼称する．次に，図 形をトレースログの内容に従い配置する座標である， 時間と高さを次元にもつ仮想的な座標をワールド座 標系と呼称する．ワールド座標系へ割り当てられた図 形は，表示開始時刻と単位時間あたりのピクセル数 により表示デバイスに表示される．このとき，表示先 の座標系をデバイス座標系と呼称する．単位時間あ たりに，何ピクセル数でワールド座標系をデバイス 座標系に割り当てるかという処理が，表示上の拡大， 縮小の処理となる． 以上の可視化表示の仕組みの抽象化から，ユーザ が任意の可視化表示項目を実現するために，汎用的 な可視化表示の仕組みに対して与える指示としては， どのような図形を，どの時間領域に割り当てるかとい うことであると考えられる． 時間領域の開始時刻と終了時刻は，イベントを用い て指定することとした．つまり，指定されたイベント が発生する時刻をトレースログより抽出することに より表示期間を決定する．このようにして，トレース ログのイベントと可視化表現を対応付ける．ここで， 開始時刻に対応するイベントを開始イベント，終了時 刻に対応するイベントを終了イベントと呼称し，表示 期間をイベントで表現したものをイベント期間と呼 称する． 4. 3. 2 図形の定義と可視化ルール 図形は楕円，多角形，四角形，線分，矢印，扇形， 文字列の7種類を用意する．図形は，形状や大きさ，
図 8 図形の定義と可視化ルールの例 位置，塗りつぶしの色，線の色，線種，透明度などの 属性を指示することができる． どの図形をどの時間領域に割り当てるか，つまり， 図形をワールド座標系のどの領域に割り当てるかの 指示は，割り当て先の領域に対して一般的でなければ ならない．つまり，割り当て先の個々の領域をすべて 指定するのではなく，ルールに基づいて割り当てが行 われるように指定されるべきである．このルールを可 視化ルールと呼称する． すなわち，可視化は，標準形式トレースログに対し て，可視化ルールを適用して，指定された開始イベン トと終了イベントに一致するイベントを標準形式ト レースログから探し，そのイベントの時刻を割り当て 先の時間領域として採用することで，ワールド座標系 への割り当てを行う． 4. 3. 3 図形の定義と可視化ルールの例 図8に図形の定義と可視化ルールの例を示す． 図形は，位置がローカル座標の原点，大きさがワー ルド座標系のマッピング領域に対して横幅100%，縦 幅80%の長方形で色が緑色の図形をrunningShape として定義している． 可視化ルール(taskBecomeRunning)では，この 図形を，開始イベントMAIN_TASK.state=RUNNING， 終了イベントMAIN_TASK.state となるイベント期 間 で 表 示 す る よ う 指 定 し て い る ．開 始 イ ベ ン ト MAIN_TASK.state=RUNNINGは，リソースMAIN_TASK の 属 性state の 値 がRUNNING に なった こ と を 表 し，終了イベントMAIN_TASK.stateは，リソース MAIN_TASKの属性stateの値が単に変わったことを 表している． この可視ルールを図8右側中央のトレースログに 適応すると，トレースログからイベントを抽出して時 間領域を決定して，図形をワールド座標にマッピング する．
5 実装
本章では，前章で行った設計を基にしたTLVの実 装について述べる．まず全体の構成について説明す る．次に変換ルールや可視化ルールをどのように形式 化したか，また，それらをどのように用いて可視化を 行うのかを説明する． TLVの実装言語はC#3.0であり，統合開発環境 としてMicrosoft社のVisural Studio 2008 Profes-sional Editionを用いた． 5. 1 構成 図9にTLVの構成を示す．TLVは，6種の入出力 ファイルと2つの主たる処理によって構成される． トレースログをTLVにより可視化表示する際，ユー ザは，トレースログファイルとリソースファイルを用 意する．また，対応する変換ルールファイルとリソー スヘッダファイル及び可視化ルールファイルを用意 する． 標準形式変換は，トレースログファイルとリソース ファイルを読み込み，リソースファイルで指定された リソースヘッダファイルと変換ルールファイルの定義 に従い，標準形式のトレースログを生成する． 図形データ生成は，生成された標準形式のトレー スログに可視化ルールファイルで定義される可視化 ルールを適用し図形データを生成した後，画面に表示 する． それぞれの処理で生成された標準形式のトレース ログと図形データは，TLVデータとしてまとめられ 可視化表示の元データとして用いられる．TLVデー タはTLVファイルとして外部ファイルに保存するこ とが可能であり，TLVファイルを読み込むことで，2 つの処理を省略して可視化表示することができる．図 9 TLV の構成 TLV が 扱 う 6 種 の ファイ ル の う ち ，ト レ ー ス ロ グ ファイ ル 以 外 は JSON(JavaScript Object Notation)[20] と 呼 ば れ る デ ー タ 記 述 言 語 を 用 い て 記 述 す る ．JSON は ，主 に ウェブ ブ ラ ウ ザ な ど で 使 用 さ れ る ECMA-262，revision 3 準 拠 の JavaScript(ECMAScript)と呼ばれるスクリプト言 語のオブジェクト表記法をベースとしており，RFC 4627として仕様が規定されている．JSONの特徴は， 構文が単純であることである．そのため，人間にとっ ても読み書きが容易であり，コンピュータにとっても 解析が容易であるため，ユーザの記述コスト，習得コ スト，またファイルの解析を行う実装コストを低減す ることができる． 5. 2 トレースログファイル トレースログファイルは，可視化対象となる環境が 出力した，任意の形式のトレースログをファイル化し たものである．トレースログファイルはテキストファ イルであり，行単位でトレースログが記述されていな ければならない．これ以外のシンタックス，セマン ティクスに関する制限はない． 5. 3 リソースヘッダファイル リソースヘッダファイルには，可視化対象の環境の リソースタイプの定義を記述する．リソースタイプ の定義には，リソースタイプの名前，表示名，属性， 振る舞いを記述する． 図10に，ASPカーネルのリソースタイプTaskを 1 "Task":{ /*リソースタイプの名前 */ 2 "DisplayName":"タ スク", /*表示名 */ 3 "Attributes":{ /*属性の定義始まり */ 4 "id":{ /*属性名 */ 5 "VariableType" :"Number",/* 属性の型 */ 6 "DisplayName" :"ID", /*属性の表示名 */ 7 "AllocationType":"Static",/* 値は動的か静的か */ 8 "CanGrouping" :false /*同じ属性値同士でグループ */ 8 }, /* を構成できるか (GUI 用) */ 10 "state":{ 11 "VariableType" :"String", 12 "DisplayName" :"状態", 13 "AllocationType" :"Dynamic", 14 "CanGrouping" :false, 15 "Default" :"DORMANT" 16 } 17 /* ... 省略 ... */ 18 }, /* 属性の定義終わり */ 19 "Behaviors":{ /* 振る舞いの定義開始 */ 20 /* ... 省略 ... */ 21 "enterSVC":{ /*システムコールの呼び出し */ 22 "DisplayName":"サ ービスコールに入る", 23 "Arguments":{"name":"String","args":"String"} 24 }, 25 /* ... 省略 ... */ 26 } 27 } 図 10 ASP カーネルのリソースヘッダファイルの一部 定義したリソースヘッダファイルの例を示す．属性 (Attribute)としては，タスクID (id)と状態(state) が定義されている．属性には，型(VariableType)，表 示名(DisplayName)，値が動的か静的か (Allocation-Type)，グループ化可能か(CanGrouping)，初期値 (Default)を指定可能である．タスクIDは実行中に 変化しないため，AllocationTypeは“Static”に，状 態は実行中に変化するため，“Dynamic”が指定され ている．なお，属性のCanGroupingを“true”とす ると，後述するTLVのリソースウィンドウにおいて， その属性の初期値でグループ化されたツーリービュー 形式で表示することができる． 振る舞い(Behaviors)としては，システムコール呼 び出し(enterSVC)が定義されている．振る舞いは， 表示名(DisplayName)，引数(Arguments)を指定可 能である． 5. 4 リソースファイル リソースファイルには，アプリケーション(応用) 毎に，主にトレースログに登場するリソースの定義 を記述する．他にも，時間の単位や時間の基数，適用 する変換ルールファイル，リソースヘッダファイル， 可視化ルールファイルを定義する．リソースの定義に
1 "TimeScale" :"us", "TimeRadix" :10, /*時刻の単位と基数 */ 2 "ConvertRules" :["asp"], /* 変換ルール指定 */ 3 "VisualizeRules" :["toppers","asp"], /*可視化ルール指定 */ 4 "ResourceHeaders":["asp"], /*リソースヘッダ指定 */ 5 "Resources":{ /*リソースの定義始まり */ 6 "TASK1":{ /* TASK1という名前のリソースを定義 */ 7 "Type":"Task", /* リソースタイプ */ 8 "Color":"ff0000", /*リソース固有の色 (GUI 用) */ 9 "Attributes":{ /*属性の初期値を指定 */ 10 "id" :1, 11 "state" :"DORMANT", 12 /* ...省略 ... */ 13 } 14 }, 15 /* ...省略 ... */ 図 11 ASP カーネル上で動作するアプリケーションの リソースファイルの一部 は，名前とリソースタイプ，属性の初期値を記述する． ASPカーネル上で動作するアプリケーションのリ ソースファイルの例を図11に示す．図10のリソース ヘッダファイルを適用するよう指定している．リソー スとしては，リソースタイプTaskのTASK1を定義し て，属性の初期値を指定している．TASK1は，タスク IDが1であり，初期状態が休止状態(DORMANT) である． 5. 5 変換ルールファイルと標準形式変換 変換ルールファイルには，ターゲットとなるトレー スログを標準形式のトレースログに変換するための ルールが記述される． 図12に，4. 2節で述べた変換ルールの例を形式化 したものを示す．1行目は，元のトレースログファイ ルから「あるタスクにディスパッチされた(図4の3 行目)」というトレースログを検索するための正規表 現であり，マッチした場合に2∼7行目で指定される 標準形式のトレースログを出力する．3行目は，出力 する条件の制御であり，条件中に$EXIST{resource} という置換マクロを用いてリソースresourceの有無 を判定している．ここでは，実行状態のタスクが存在 するかチェックして，存在すれば，そのタスクが実行 可能状態となる標準形式のトレースログ(4行目)を 出力する．一方，7行目は，1行目のマッチにより無 条件に出力され，ディスパッチ先のタスクの状態を実 行状態とする標準形式トレースログを出力する．9∼ 13行目は，システムコール呼び出しを変換するため の変換ルールである．
1 "\[(?<t>\d+)\] dispatch to task (?<id>\d+)\.":[ 2 { 3 "$EXIST{Task(state==RUNNING)}":[ 4 "[${t}]Task(state==RUNNING).state=READY", 5 ] 6 }, 7 "[${t}]Task(id==${id}).state=RUNNING", 8 ],
9 "\[(?<time>\d+)\] enter to (?<name>(i\w+[_]\w+)) \ 10 ( (?<args>.+))?\.?" :[ 11 "[${time}]$ATTR{CurrentContext.name}.enterSVC( \ 12 ${name}, ${args})" 13 ], 図 12 ASP カーネルの変換ルールファイルの一部 置換マクロは6種類用意されており，特定リソース の有無や数，属性の値を得ることができる．また，置 換マクロは，条件判定のときだけでなく，出力する標 準形式トレースログの記述にも用いることができる． • $EXIST{resource} 指定されたリソースが存在すればtrue，存在し なければfalseに置換する． • $COUNT{resource} 指定されたリソースの数に置換する． • $ATTR{attribute} 指定された属性の値に置換する． • $RES_NAME{resource} 指定されたリソースの名前に置換する • $RES_DISPLAYNAME{resource} 指定されたリソースの表示名に置換する． • $RES_COLOR{resource} 指定されたリソースの色に置換する． 標準形式変換は，トレースログファイルを先頭から 行単位で読み込み，変換ルールファイルで定義される 置換ルールに従い標準形式のトレースログに置換す ることで行われる．図13に図4のトレースログを図 12の変換ルールを用いて標準形式のトレースログに 変換した例を示す． なお，図6と異なり，タスクの指定を，“TASK1” という文字列を使わず，リソースタイプTaskのタス クIDの属性の条件(Task(id==1))でTASK1を指 定している．直接文字列を生成したい場合は，変換 ルールで$RES NAMEの置換マクロを用いればよい．具 体的には，図12の7行目にあるTask(id==${id}) を$RES NAME{}で囲む．
1 [1000]Task(state==RUNNING).enterSVC(act_tsk, tskid=1) 2 [1005]Task(id==1).state=READY 3 [1010]Task(state==RUNNING).state=READY 4 [1010]Task(id==1).state=RUNNING 図 13 図 4 のトレースログの図 12 の変換ルールによる 標準形式への変換結果 1 "toppers":{ 2 "Shapes":{ /*図形の定義始まり */ 3 "runningShapes":[{ 4 "Type":"Rectangle", /*形状の指定 (長方形) */ 5 "Size":"100%,80%", /*大きさの指定 */ 6 "Pen":{"Color":"ff00ff00","Width":1},/*線種の指定 */ 7 "Fill":"6600ff00" /*塗りつぶしの指定 */ 8 }], 9 /* ...省略 ... */ 10 }, /*図形の定義終わり */ 11 "VisualizeRules":{ /*可視化ルールの定義始まり */ 12 "taskStateChange":{ 13 "DisplayName":"状 態遷移", /* 可視化ルールの表示名 */ 14 "Target":"Task", /* 適用するリソースタイプ */ 15 "Shapes":{ /*表示項目の指定 */ 16 "stateChangeEvent":{ 17 "DisplayName":"状 態", /* 表示項目の表示名 */ 18 "From":"${TARGET}.state", /*開始イベント */ 19 "To" :"${TARGET}.state", /*終了イベント */ 20 "Figures":{ /*表示する図形 */ 21 "${FROM_VAL}==RUNNING" :"runningShapes", 22 "${FROM_VAL}==READY":"readyShapes" 23 /* ...省略 ... */ 24 } 25 }, 26 /* ...省略 ... */ 27 } 28 }, /*可視化ルールの定義終わり */ 29 /* ...省略 ... */ 図 14 ASP カーネルの可視化ルールファイルの一部 5. 6 可視化ルールと図形データ作成 図形と可視化ルールの定義は可視化ルールファイ ルに記述する．図14にASPカーネルの可視化ルー ルファイルの一部を示す．2行目から10行目までが 図形の定義であり，それ以降が可視化ルールの定義で ある． 図形としては，長方形のrunningShapesが定義さ れている．可視化ルールは，RTOSのタスクの状態表 示のためのtaskStateChangeが定義されている．こ のルールでは，リソースタイプであるタスク(Task) を対象とすることを，Targetで指定している．開始 イベント(From)と終了イベント(To)として，タスク の属性であるタスクの状態の値の変更イベントを用 いることを指定している．そして，Figuresで，ワー ルド座標系に割り当てる図形を指定している．この ルールでは，変更後の属性の値(タスクの状態)によっ て可視化方法を切り替えており，実行状態の場合は， runningShapesを用いる． 図形データ生成は，4. 3節で述べたとおり，標準形 式トレースログの内容と図形と可視化ルールの定義 に従い，ワールド座標系に図形を割り当てる．
6 TLV のユーザインタフェース
TLVのユーザインタフェースについて解説する． 図15に，ASPカーネルが出力したトレースログを， TLVを用いて可視化表示した結果を示す． 6. 1 可視化表示部の制御 可視化表示ツールでは，可視化表示部(図中の中央 上側のペイン)を制御する操作性が使い勝手に大きく 影響するため，TLVでは目的や好みに合わせて様々 な操作で制御を行えるようにした．TLVでは，可視 化表示部の制御として，表示領域の拡大縮小，移動を 行うことができる．これらの操作方法として，キー ボードによる操作，マウスによる操作，値の入力によ る操作の3つの方法を提供した． マウスによる操作は，ドラッグによる操作，ホイー ルによる操作がある．ドラッグによる操作は，直接可 視化表示部をドラッグして，表示領域を移動させる． ホイールによる操作は，コントロールキーを押しなが らホイールすることで移動を行い，シフトキーを押し ながら上へホイールすることでカーソル位置を中心 に拡大，下へスクロールすることで縮小する． キーボードによる操作は，可視化表示部において 方向キーを押すことで行い，微調整に適している．左 キーで表示領域を左に移動し，右キーで右に移動す る．上キーでカーソル位置，または選択されたマー カーを中心に表示領域を縮小し，下キーで拡大する． 値の入力による操作では，より詳細な制御を行うこ とができる．可視化表示部の上部にはツールバーが用 意されており，そこで表示領域の開始時刻と終了時刻 を直接入力することができる． 6. 2 マクロ表示 可視化表示部で拡大した場合にログ全体のどの部 分を表示しているのかを知るために，マクロビューア図 15 TOPPERS/ASP カーネルのトレースログの可視化表示 (図中の一番下のペイン)を用意した． マクロビューアでは，トレースログに含まれるイベ ントの最小時刻から最大時刻までを常に可視化表示 しているウィンドウで，可視化表示部で表示してい る時間を半透明の色で塗りつぶして表示する．塗り つぶし領域のサイズをマウスで変更することができ， それに対応して可視化表示部の表示領域を変更する ことができる． マクロビューアでは可視化表示部と同じように， キーボード，マウスにより拡大縮小，移動の制御を行 うことができる． 6. 2. 1 トレースログのテキスト表示 標準形式のトレースログをテキストで表示するウィ ンドウを用意した(図中の右側のペイン)．ここでは， トレースログの内容を確認することができる． 可視化表示部とテキスト表示ウィンドウは連携し ており，テキスト表示ウィンドウでマウスを移動する と，カーソル位置にあるトレースログの時刻にあわせ て可視化表示部のカーソルが表示されたり，ダブルク リックすることで対応する時刻に可視化表示部を移 動することができる．また，可視化表示部でダブルク リックすることで，ダブルクリック位置にある図形に 対応したトレースログが，テキスト表示ウィンドウの 先頭に表示されるようになっている． 6. 2. 2 可視化表示項目の表示・非表示切り替え TLVでは，可視化表示する項目を可視化ルールに より変更，追加することができるが，それらの表示を 可視化ルールやリソースを単位で切り替えることが できる．これらの操作は，リソースウィンドウと可視 化ルールウィンドウで行う(図中の左側のペイン)． リソースウィンドウではリソースファイルで定義さ れたリソースを，リソースタイプやグループ化可能な 属性毎にツリービュー形式で表示しており，チェック の有無でリソース毎に表示の切り替えを行える．ASP カーネルの場合は，タスクの優先度がグループ化可 能と指定されており，図16に示すように，リソース ウィンドウで，優先度の初期値でグループ化されたツ リービュー形式の表示が選択可能である．
図 16 タスクの優先度の初期値でグループ化された ツリービュー形式の表示 可視化ルールウィンドウでは，可視化ルールごとに 表示の切り替えを行える．
7 評価
汎用性の評価として，トレースログの形式が異なる RTOS(ASPカーネル)及びソフトウェアコンポーネ ント(TECS)[23]のトレースログを可視化する．次に， 拡張性の評価として，ASPカーネルをマルチプロセッ サ拡張したFMPカーネルの可視化をASPカーネル 用のファイルをベースに拡張して可視化表示する． また，TLVは多くの既存のツールと異なり，デバッ ガソフトウェアや統合開発環境とは独立したプログラ ムである．そのために生じる制約や課題について述 べる． 7. 1 ASPカーネルの可視化表示 図15に，ASPカーネルが出力するトレースログ を，TLVを用いて可視化表示した結果を示す．緑色 の長方形がタスクが実行状態であることを示してい る．MAIN TASKはシステムコール(act tsk(1))を 呼び出して，タスクIDが1のTASK1を起動(上矢 印)して実行可能状態(平行ライン)としている．起 動の結果，TASK1はMAIN TASKより優先度が高 いため，ディスパッチが発生して，TASK1が実行状 態MAIN TASKが実行可能状態に遷移し，TASK1 にディスパッチしている．このように，タスクの状態 遷移やシステムコールの出入り，その際の引数，返値 を可視化表示できていることがわかる． 変換ルールファイルは136行であり，可視化ルール ファイルは可視化ルールが346行，図形の定義が198 行であった．また，リソースヘッダファイルは412行 であった． 1 time=timeus caller->callee.enter(...) 2 time=timeus caller->callee.leave(...) 図 17 TECS のセルの呼び出しのトレースログの形式 7. 2 ソフトウェアコンポーネント(TECS)の 可視化表示 組込みコンポーネントシステムTECS(TOPPERS Embedded Component System)のトレースログを 用いた．TECSとは，組込みに適したソフトウェア の部品化の仕組みで，セルと呼ばれるコンポーネント のインスタンス同士を接続することでソフトウェア を構築する．セルは呼び口，受け口を持ち，それぞれ シグニチャを持つ．同じシグニチャ同士の呼び口と受 け口を接続することができる．シグニチャは関数ヘッ ダの集合で，複数の関数インタフェースを持つ． TECSのトレースログを可視化表示する項目とし て，セルの呼び出し関係を採用した．簡略化のため， セルがシグニチャのどの関数を呼んだかどうかは可視 化せず，どのセルが，どのセルを，どのくらいの期間 呼び出していたかを可視化表示するとする．セルの呼 び出しのトレースログの形式を図17に示す． timeは時間であり，時間の単位はマイクロ秒であ る．callerは呼び出しセルを，calleeは呼び出される セルを表している．...には，シグニチャの名前や引数， 返値が入るが，今回の可視化には必要がないので省略 した．.enter(...)がセルの呼び出しを，.leave(...) が呼び出し先からのリターンを表している． 図18に，TLV用いて可視化表示した結果を示す． セルの呼び出し関係が可視化表示できていることが わかる．これにより，TLVを用いることで形式の異 なるトレースログを可視化できることが示せた．こ のとき，変換ルールファイルは15行であり，可視化 ルールファイルは可視化ルールが39行，図形定義が 49行であった．また，リソースヘッダファイルは47 行であった． 7. 3 FMPカーネルの可視化表示 次に，ASPカーネルをマルチプロセッサ用に拡張 したFMPカーネルが出力するトレースログの可視化 表示をASPカーネル用のファイルを拡張することで図 18 ソフトウェアコンポーネント (TECS) のトレースログの可視化表示 行った．FMPカーネルが出力するトレースログの形 式は，図1に示すように，ASPカーネルが出力する トレースログの形式に，プロセッサの番号を付加し た形式になっている．また，FMPカーネルの可視化 表示項目は，ASPカーネルの可視化表示項目に加え， そのタスクを実行しているプロセッサを背景色で区別 するように拡張したものとする． 図19に，FMPカーネルが出力するトレースログ を，TLV用いて可視化表示した結果を示す．タスク の状態遷移を表示している箇所に，背景色で実行プ ロセッサを区別し表現している．背景色が薄い箇所は プロセッサ1を背景色が濃い箇所はプロセッサ2を 示している．FMPカーネルでは，mig tsk()と呼ば れるシステムコールを呼び出すことで，実行するプ ロセッサを変更することができる(タスクマイグレー ション)．図19を見ると，TASK1 1からTASK1 3 がそれぞれ，mig tsk()を呼び出すと，背景の色が変 化し，タスクマイグレーションが発生していることが 分かる． 変換ルールファイルは160行，可視化ルールファ イルは可視化ルールが250行，図形定義が30行，リ ソースヘッダファイルは439行となった．可視化ルー ルファイルはASPカーネル用の可視化ルールファイ ルに対する追加ルールとなっている．以上により，拡 張性が確認できた． 7. 4 TLVの制約と課題 TLVは独立したプログラムであるため，デバッガ ソフトウェアや統合開発環境に組み込まれた可視化 ツール(以下，統合可視化ツール)と比較すると，ユー ザ操作の煩雑性，処理速度，機能面での制約や課題が ある． ユーザ操作の煩雑性に関しては，統合可視化ツール の場合は，一般的にデバッガソフトウェアや統合開発 環境のメニュー等で可視化を選択するだけで，自動的 に可視化が可能である．一方，TLVの場合は，一旦 トレースログをトレースログファイルに保存してか ら，TLVを起動して，読み込ませる必要がある．ま た，トレースログファイルと共にアプリケーション毎 にリソースファイルが必要となるが，リソースファイ
図 19 マルチプロセッサ対応 RTOS(TOPPERS/FMP カーネル) のトレースログの可視化表示 ルを自動的に生成できない場合は，ユーザが手作業で 用意する必要がある． 処理速度に関しては，統合可視化ツールはログの形 式や可視化項目を固定化しているのに対して，TLV では，トレースログの形式や可視化項目の自由度を もたせるため，変換ルールによる標準形式変換や可 視化ルールによる図形データ生成が必要であるため， TLVの方が可視化に要する時間が長くなると考えら れる． 機能面としては，統合可視化ツールには，プロセッ サやシミュレータを停止してその時点までのトレー スログを可視化した後，処理を再開して得られたト レースログを追加して可視化することが可能なもの がある．一方，現状のTLVでは，あるトレースログ ファイルを可視化表示している状態で，続きのトレー スログを新たに読み込ませて追加して可視化表示す ることはできない．
8 おわりに
本論文では，トレースログ可視化ツールであるTLV について，背景と既存ツールの問題点，それを解決す るための要件，要件を満たすための方法とその実装， 評価について述べた． 今後の課題としては，現状の変換ルールや可視化 ルールの記述では実現できない，計算の必要な可視化 表示項目について検討することが挙げられる．例え ば，RTOSにおけるCPU使用率等の可視化表示等 である．これらの可視化項目を扱うには，可視化ルー ルを現状の単純なイベントの指定ではなく，イベント の状態遷移で指定できるようにする方法や，変換ルー ルをスクリプト言語化する方法などが考えられる． 参 考 文 献 [ 1 ] TraceLogVisualizer(TLV), http://www.toppers. jp/tlv.html. [ 2 ] OJL による最先端技術適応能力を持つ IT 人材育成 拠点の形成, http://www.ocean.is.nagoya-u.ac.jp/[ 3 ] 小林隆志, 沢田篤史, 山本晋一郎, 野呂昌満, 阿草清 滋: On the Job Learning: 産学連携による新しいソ フトウェア工学教育手法, 電子情報通信学会 信学技報 SS2009-28, (Vol. 109, No. 170, pp. 95–100), 2009. [ 4 ] TOPPERS/FMP kernel，http://www.toppers.
jp/fmp-kernel.html.
[ 5 ] Gestwicki, P. and Jayaraman, B.: Methodology and architecture of JIVE, in Proceedings of the 2005
ACM symposium on Soft-ware Visualization (Soft-Vis’05), 2005, pp.95–104.
[ 6 ] Pillet, V., Labrata, J., Cortes, T. and Girona, S.: PARAVER: A tool to visualise and analyze paral-lel code, in Proceedings of WoTUG-18: Transputer
and occam Developments, IOS Press, Vol. 44, 1995,
pp. 17–31.
[ 7 ] Nagel,W. E., Arnold, A., Weber,M. and Solchen-bach, K.: VAMPIR Visualization and Analysis of MPI Resources, Supercomputer 63, Vol. 12, No. 1 (1996), pp. 69–80.
[ 8 ] Zaki,O., Lusk, E., Gropp,W. and Swider, D.: Toward Scalable Performance Visualization with Jumpshot, High-Performance Computing
Applica-tions, Vol. 13, No. 2 (1999), pp. 277–288.
[ 9 ] 上嶋明, 小畑正貴, 金田悠紀夫 : Omni OpenMP コンパイラ用並列プログラム可視化ツール (プ ログ ラミングモデル・ツール), 情報処理学会論文誌, コン ピューティングシステム, 46(SIG 12(ACS 11)) (2005), pp. 205–213.
[10] de Kergommeaux, J. C., de Oliveira Stein, B. and Bernard P.E. : Paj`e , an interactive visualiza-tion tool for tuning multi-threaded parallel appli-cations, Parallel Computing, Vol. 26, No. 10 (2000), pp. 1253–1274.
[11] Visual Trace Explorer, http://vite.gforge.inria. fr/.
[12] JTAG ICE PARTNER-Jet，http://www.kmckk.
co.jp/jet/.
[13] WatchPoint デバッガ，https://www.sophia-systems.co.jp/.
[14] QNX Momentics Tool Suite，http://www.qnx. co.jp/products/tools/.
[15] eBinder，http://www.esol.co.jp/embedded/ ebinder.html.
[16] Desnoyers, M. and Dagenais, M.: The lttng tracer : A low impact performance and behavior monitor for gnu/linux, in OLS (Ottawa Linux
Sym-posium) 2006, 2006, pp. 209–224.
[17] Desnoyers, M. and Dagenais, M.: OS Tracing for Hardware, Driver and Binary Reverse Engineer-ing in Linux, CodeBreakers Journal Article, Vol. 4, No. 1, 2007.
[18] McDougall, R., Mauro, J. and Gregg, B.: So-laris(TM) Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris, Pearson Professional, 2006.
[19] OpenSolaris Project: Chime Visualization Tool for DTrace，http://opensolaris.org/os/project/ dtrace-chime/.
[20] RFC4627 The application/json Media Type for JavaScript Object Notation (JSON)，http://tools. ietf.org/html/rfc4627.
[21] TOPPERS ASP Kernel，http://www.toppers. jp/asp-kernel.html.
[22] 坂 村 健 監 修, 高 田 広 章 編 : µITRON4.0 仕 様 Ver.4.02.00, トロン協会, 2004.
[23] Azumi, T., Yamamoto, M., Kominami, Y., Tak-agi, N., Oyama, H. and Takada, H.: A New Specifi-cation of Software Components for Embedded Sys-tems, in Proceedings of the 10th IEEE International
Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC 2007),
