Embed Size (px)
Citation preview
修士論文
電磁カロリメータ FORESTのための
ネットワーク分散型データ収集系の開発
東北大学大学院理学研究科
物理学専攻
岡田 康友紀
平成 19年
電磁カロリメータFORESTのためのネットワーク分散型データ収集系の開発
岡田康友紀
1 本研究の背景と目的
これまで東北大学大学院理学研究科附属原子核理学研究施設（核理研）では、高エネルギーガンマ線を用いて原子核中での核子共鳴状態の性質変化の研究がされてきた。核子共鳴状態の崩壊過程で生成される π0、η 中間子には 2つのガンマ線に崩壊するモードがある。原子核での核子共鳴状態を詳細に調べるために多重ガンマ線検出器群 SCISSORSIIでこれらのガンマ線を検出してきた。しかしながら SCISSORS IIは全立体角の約 13%しか覆っていなかったため、γγ不変質量分布での 1つの中性中間子が崩壊したのではない 2つのガンマ線によるバックグラウンドが存在した。また立体角が小さいため、終状態を完全に把握することは難しかった。そこで、全立体角の約 90%以上を覆う 4π 多重ガンマ線検出器群 FORESTの建設が開始された。
図 1: 多重ガンマ線検出器群FOREST。現在までに手前に見える前方検出器群 SISSORS IIIと中央の極角 30◦–100◦ を覆う検出器群 Backward Gammaの建設が終了している。
新検出器群FORESTはSCISSORS II検出器と比較して構成する検出器数が倍増するため、実験で収集するデータ量が大幅に増加する。またSCISSORSII検出器より前方角度を覆っているため、同種のトリガーを形成すればそのレートは格段に大きくな
る。これによりこれまで SCISSORS IIで用いてきたデータ収集システム（DAQシステム）では、データ収集効率が大幅に低下することが予想できた。また検出器群である FORESTの建設は段階的に行われるため、その建設状況に応じて大きな変更を必要としないで対応できるDAQシステムが望まれた。本研究では、新検出器群 FORESTに対してその
建設状況に応じて柔軟性を持ち、かつ十分な性能を発揮できるDAQシステムの設計を行った。
2 DAQシステムの設計
高いデータ収集効率と柔軟性を得るため、DAQシステムをネットワーク分散型システムとして設計した。データの収集、構築、記録といった処理をネットワーク上に分散された複数のプロセスで並列的に行う。これにより収集するデータ量の増加に対して複数のサブシステムを用意することができ、データの読み出しにかかる負荷を軽減することができる。またサブシステムの追加が容易に行えるため、DAQシステム全体に大幅な改良を必要とせず、検出器の建設状況といった実験状況に対して一定の柔軟性を持つことができる。図 2にネットワーク分散型システムの概略を示す。データフローレイヤー、プロセス管理レイヤー、
ログ管理レイヤーから構成されるネットワーク分散型のDAQソフトウェアを設計した。データフローレイヤーでは、複数のサブシステムで読み出されたデータをイベントとして構築し保存するといったデータの流れを管理する。プロセス管理レイヤーでは、ネットワーク上に分散したプロセスの起動や終了といったプロセスの制御を行う。ログ管理レイヤーでは、ネットワーク上に分散したプロセスの活動ログを一括して監視する。この 3つのレイヤーにおけるプロセスによってDAQシステム全体の管理を行う。
1
図 2: ネットワーク分散型システムの概略図。データ、コマンド、ログの流れを矢印で示した。実際にはそれぞれがレイヤーに分離されて管理される。
3 DAQシステムの実装と性能評価
DAQシステムのデータ収集効率を決定するのはデータフローレイヤーのプロセスである。データフローレイヤーとして、1）ハードウェアからデータの読み出しを行うコレクター、2）複数のコレクターで収集されたデータを 1つのイベントとして構築するイベントビルダー、3）データのハードディスクへの記録を行うレコーダー、4）データ収集中にリアルタイムでデータをモニターするオンラインモニターの 4つのプロセスを実装した。これらのプロセスを用いて検出器群 FORESTのデータ収集を行い、開発したDAQソフトウェアが正しくデータを収集し、かつ十分なデータ収集効率を達成しているかどうかの性能評価を行った。イベント IDの確認複数のサブシステムでデータ収集を行うため、同
一のトリガーに対するデータが正しくイベントとして構築されているかを確かめた。すべてのサブシステムで収集するデータの中にイベント IDとなるタグを埋め込み、それをオンラインモニターで監視することでイベントが正しく構築されていることを確認しながらデータ収集を行った。ライブタイムの測定
FOREST のデータ収集は、TKO-SMP、VME-TDC、FERA-UIOという 3つのサブシステムを作成して行った。全体のライブタイムはトリガーレート約 1.5 kHzに対して 70%弱程度であった。各サブシステムと全体のライブタイムを図 3に示す。各サブシステムがデータの読み出しにかかる時間（不感時間）を測定してライブタイムのシミュレーション
を行ったところ、測定値と一致した。このことから、DAQシステムの性能はサブシステムのハードウェアからのデータの読み出しにかかる時間で決定されており、イベントビルダー、レコーダーのデータ処理で速度低下をまねいていないことを確認した。ほぼ全体の性能を決定しているのは TKO-SMPコレクターであり、TKO-SMPコレクターで使用しているTKO規格のモジュールはより高速なデータ読み出しが可能なVMEbus規格のものへの移行を検討している。これによって全体の性能を向上させることが可能であると考えている。
図 3: DAQシステム全体のライブタイムと各コレクター別に測定したライブタイム。
オンラインモニター実装したオンラインモニターの動作確認を行っ
た。オンラインモニターでデータ収集中の各検出器のADC、TDCデータのヒストグラムの表示等を行い、データ収集中にデータが正しく収集できているかを確認した。
4 まとめ
新検出器群 FOREST用のDAQシステムを設計し、データフローを管理するプロセスを実装した。実際にビームを用いて FOREST検出器のデータ収集を行うことで開発したプロセスの性能評価を行い、設計した DAQソフトウェアが新検出器 FOREST用として十分に動作していることを確認した。
2
目 次
第 1章 序論 61.1 DAQシステム開発の背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 核理研での研究 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.2 GeVγビームライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.3 大立体角ガンマ線検出器群 FOREST . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 新しいDAQシステムの必要性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 本研究の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
第 2章 FOREST実験で収集するデータ 112.1 データの大きさ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 トリガー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
第 3章 DAQソフトウェアの設計 163.1 ネットワーク分散型システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 データフローレイヤー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 通信方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 プロセス管理レイヤー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 プロセスマネージャー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2 プロセスマネージャーゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.3 プロセスコントローラー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.4 通信方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 ログ管理レイヤー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4.1 ログウォッチャー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4.2 ログウォッチャーゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.3 ログモニター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
第 4章 データフローを管理するプロセスの実装 264.1 コレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 コレクターでの処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.1.2 ユーザーが実装する処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.3 バッファハンドリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.4 スローコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.5 デモコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 イベントビルダー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.1 イベントビルダーの処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.2 スローコレクターのデータのイベント構築 . . . . . . . . . . . . . . . . . . . . . 404.2.3 マルチキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 レコーダー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 オンラインモニター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1
4.4.1 オンラインモニターでの処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.2 ユーザーが実装する処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 コマンド制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.1 データ収集開始時のコマンドの流れ . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.2 データ収集停止時のコマンドの流れ . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 データフォーマット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.6.1 パケット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.6.2 ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6.3 データ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.6.4 ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
第 5章 FORESTのデータ収集での性能評価 545.1 実験セットアップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1 TKO-SMPコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.2 VME-TDCコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.1.3 FERA-UIOコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.1.4 スローコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.1.5 トリガーシステム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 ライブタイムの測定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.1 測定結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2.2 シミュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.3 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 オンラインモニタリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.3.1 Event Sync IDの表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.3.2 各検出器のADC、TDC分布の表示 . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.3 検出器のヒットパターンの表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4 データ解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.1 クラスタリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.4.2 クラスターのエネルギーと位置 . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.4.3 γγ不変質量 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
第 6章 まとめ 74
2
図 目 次
1.1 ガンマ線検出器 SCISSORS II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 γ p → η p反応の全断面積 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 GeVγビームラインの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 STB-Tagger IIの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 4πガンマ線検出器群 FOREST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 SCISSORS IIIと Backward Gammaのブロック分割。 . . . . . . . . . . . . . . . . . . 132.2 トリガーの概略図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 ネットワーク上に分散されたプロセスの様子。 . . . . . . . . . . . . . . . . . . . . . . . 173.2 DAQソフトウェアのレイヤー構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 データフローレイヤーの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 プロセス管理レイヤーの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 プロセスマネージャーによるプロセスのコマンドの制御の様子 . . . . . . . . . . . . . . 223.6 ログ管理レイヤーの概略図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.7 ログウォッチャーの概略図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 コレクターの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 コレクターのマルチスレッド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 マルチプロセスとマルチスレッドの概念図 . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 コレクターの処理の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5 共有バッファの概念図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.6 複数イベント分のデータのバッファリングの様子 . . . . . . . . . . . . . . . . . . . . . 324.7 共有バッファの構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.8 クリティカルセクションの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.9 Mutexを用いた処理の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.10 スローコレクターの概念図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.11 デモコレクターの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.12 デモコレクターの処理の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.13 イベントビルダーの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.14 イベントビルダーのマルチスレッド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.15 スローコレクターのデータのイベント構築の様子 . . . . . . . . . . . . . . . . . . . . . 404.16 マルチキャストでのデータ通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.17 レコーダーの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.18 オンラインモニターの概観図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.19 オンラインモニターの処理の流れ。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.20 パケットの形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.21 ベースヘッダの形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.22 コレクターヘッダのHeader Dataの部分 . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3
4.23 イベントビルダーのHeader Dataの部分 . . . . . . . . . . . . . . . . . . . . . . . . . . 494.24 レコーダーヘッダのHeader Dataの部分 . . . . . . . . . . . . . . . . . . . . . . . . . . 494.25 ランヘッダの形式。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.26 コレクターデータのData Bodyの部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.27 イベントデータのData Bodyの部分 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.28 ファイルの形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1 検出器のデータとコレクターの対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2 SMP-TKOコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3 SMPモジュールのダブルバッファの様子 . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4 VME-TDCコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.5 FERA-UIOコレクター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.6 BUSY信号の概念図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.7 複数のコレクターがあるときのVetoのかけかた . . . . . . . . . . . . . . . . . . . . . . 595.8 全体のライブタイムと各コレクターのライブタイム . . . . . . . . . . . . . . . . . . . . 605.9 各コレクターごとに比較したイブタイム . . . . . . . . . . . . . . . . . . . . . . . . . . 615.10 スローコレクターの有無で比較したライブタイム . . . . . . . . . . . . . . . . . . . . . 625.11 各コレクターのライブタイムとシミュレーションとの比較 . . . . . . . . . . . . . . . . 655.12 2つのコレクターを接続した場合のライブタイムとシミュレーションとの比較 . . . . . . 665.13 オンラインモニターで表示させたADC分布の例 . . . . . . . . . . . . . . . . . . . . . . 685.14 オンラインモニターで表示させた TDC分布の例 . . . . . . . . . . . . . . . . . . . . . . 695.15 SCISSORS IIIと Backward Gammaのヒットパターン . . . . . . . . . . . . . . . . . . 705.16 SCISSORS IIIでのクラスタリングの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.17 FOREST実験での γγ不変質量分布 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4
表 目 次
2.1 検出器群 FORESTを構成する検出器数 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Packet IDの一覧表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 各コレクターのイベントごとの不感時間 . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5
第1章 序論
1.1 DAQシステム開発の背景
1.1.1 核理研での研究
東北大学附属原子核理学研究施設（核理研）では、1.2 GeVの電子円形加速器から制動放射によって得られる高エネルギーガンマ線を用いて、原子核内の核子の共鳴状態の性質変化を調べる研究を目的として実験を行ってきた [1]。核子の共鳴状態の崩壊過程で生じる π0、η中間子は複数のガンマ線に崩壊するモードがある。このガンマ線を多重ガンマ線検出器で捕らえることで、その不変質量から崩壊前の中間子を同定することができる。原子核内の核子の共鳴状態を調べるために、素過程である γ p → η p反応による S11(1535)核子共鳴状態の性質変化の研究が、核理研のガンマ線検出器 SCISSORS IIを用いて行われてきた [2]。SCISSORS IIはCsIクリスタル 206本で構成されている。図 1.1に SCISSORS IIの写真と概観図を示す。
図 1.1: ガンマ線検出器 SCISSORS II。（左）SCISSORS IIの写真。前面に荷電粒子識別用のプラスチックシンチレーターが設置されている。（右）SCISSORS IIの概観図。六角錐台の形状をしている CsIクリスタル 206本で 4つのブロックを形成している。
SCISSORS II実験では γ p → η p反応の全断面積が得られ、S11(1535)の共鳴状態を確認することができた。図 1.2に γ p → η p反応の全断面積を示す。しかしながら SCISSORS IIは全立体角の約 13%しか覆っていなかっため、反応の終状態を完全に把握することは不可能であった。そこでより精度のよい実験を行うため、現在核理研では全立体角の 90 %以上を覆う 4πガンマ線検出器群 FORESTの建設を行っている。FORESTでは、水素・重水素を標的とした π0、η光生成反応に関する実験が予定されている。
6
図 1.2: γ p → η p反応の全断面積。赤丸が SCISSORS II実験で得られたデータである。
1.1.2 GeVγビームライン
核理研には、電子線を最大 300MeVまで加速できる線形加速器（LINAC）と最大 1.2GeVまで加速し周回蓄積させることができる円形加速器（STBリング）がある。LINACで 150MeVまたは 200MeVに加速された電子線を STBリングに入射し、STBリングで 920 MeVまたは 1.2GeVに加速し蓄積周回させる。この周回電子を炭素ファイバーのラジエーターにあてて制動放射を起こし、発生した高エネルギーガンマ線を実験室まで導いて標的に入射させることで実験を行っている [3]。図 1.3にGeVγビームラインの概観図を示す。ラジエーターは直径 11 µmの炭素ファイバーで、STBリング内を周回する電子に同期して周回電子の
軌道上へ挿入される。周回電子は制動放射を起こして徐々にビーム強度が弱まっていくので、生成されるガンマ線が一定の強度となるようにラジエーターの運転パラメーターを調整する。ラジエーターで制動放射を起こしてガンマ線を放出した電子は、低い運動量となるため STBリング
の偏向電磁石内で周回電子ビームよりも大きく曲げられる。STBリング内の偏向電磁石内に設置されたSTB-Tagger IIと呼ばれる 232本のシンチレーティングファイバー群で、その電子を検出する。ラジエーターに衝突した後の反跳電子を運動量分析してその軌道を決定することで、GeVγ照射室へと到達するガンマ線のエネルギーを標識化することができる [4]。図 1.4に STB-Tagger IIの概観図を示す。
1.1.3 大立体角ガンマ線検出器群FOREST
核理研では、中間子が崩壊して生成するガンマ線を多重ガンマ線検出器で捕らえることで、原子核内の核子の共鳴状態の性質変化の研究を行ってきた。SISSORS IIは全立体角の約 13%しか覆うことができなかったため、次のような問題があった。多重ガンマ線検出器は、電磁シャワーで発生した荷電粒子によるシンチレーション光の量によって、
検出器に入射したガンマ線のエネルギーを測定している。この電磁シャワーは広がりを持つため、ガン
7
図 1.3: GeVγビームラインの概観図。LINACから入射された電子を STBリング内で 1.2GeVまで加速してやり、その電子にラジエーターを挿入して発生させたガンマ線を検出器のあるGeVγ照射室まで導いている。
図 1.4: STB-Tagger IIの概観図。偏向電磁石のリターンヨークとコイルの隙間にシンチレーティングファイバー 232本が設置されている。光電子増倍管を動作させるために鉄のフェンスをリング内に挿入して磁場を抑えている。
8
マ線が入射した検出器の周りに浸みだす。ガンマ線が隣り合う検出器のない部分に入射した場合、電磁シャワーは検出器の外へ浸みだすのでガンマ線の全エネルギーを正しく測定することができず、系統誤差が大きくなる。また、η → 3π0 → 6γのような崩壊過程では、小さい立体角しか覆っていない検出器では終状態にあるガンマ線をすべて捕らえることができない。これによって相関のないガンマ線同士で不変質量を組んでしまい、不変質量分布のバックグラウンドが大きくなる。このような問題を解決するため、ほぼ 4πを覆う大立体角ガンマ線検出器群 FORESTを建設することになった。
FOREST は多重ガンマ線検出器群であり、前方ガンマ線検出器である SCISSORS III、BackwardGamma、後方ガンマ線検出器であるRafflesia II から構成され、全立体角の約 90%以上を覆う。SCIS-SORS IIIは CsIクリスタル 192本、Backward Gammaは鉛シンチレーティングファイバー 252本、Rafflesia IIは鉛チェレンコフカウンター 36本で構成される。それぞれの検出器の前面には荷電粒子識別のためのプラスチックシンチレーターが設置される。現在までに SCISSORS III、Backward Gamma、SCISSORS III用の荷電粒子識別用プラスチックシンチレーター群SPIDERの建設が終了している。図 1.5に FORESTの写真と概観図を示す。
図 1.5: 4πガンマ線検出器群 FOREST。（左）FORESTの写真。現在までに手前に見える SCISSORSIIIと中央のBackward Gammaの建設が終了し、SCISSORS IIIの前面に SPIDERが取り付けられている。（右）FORESTの概観図。FORESTは SCISSORS III、Backward Gamma、Rafflesia IIと呼ばれる 3つの検出器で構成される。
1.2 新しいDAQシステムの必要性
現在建設が進められている新検出器群 FORESTは、ほぼ 4πの立体角を覆う多重ガンマ線検出器群である。FORESTはこれまで用いられてきた検出器である SCISSORS IIと比較して、構成する検出器の数が大幅に増加し、1イベント当たりに読み出す ADCや TDCのデータ数が増加する。また FORESTは SCISSORS IIよりも前方角度を覆うため、SCISSORS IIのときと同様のトリガーを作成すればそのレートは格段に大きくなる。データ収集システム（DAQシステム）への負荷は 1イベント当たりに収集するデータの大きさとデータを収集する頻度であるトリガーレートで決定するため、SCISSORS IIで用いてきたDAQシステムではデータ収集効率が著しく低下することが予想された。FOREST実験で収集する 1イベントのデータの大きさについては § 2で詳しく述べる。FOREST実験では数 kHzのトリガーレートでのデータ収集を想定しており、具体的な新しい DAQシステムのデータ収集効率の目標値としては、2 kHzのトリガーレートで 80%を超えるデータ収集効率があることを要求している。
9
また、複数の検出器群から構成される FORESTの建設は段階的に行われていく予定である。その中途段階においてもデータ収集が容易に行えるために、建設状況に応じて大幅な変更を必要とせずに柔軟に対応できるようなDAQシステムが必要とされている。以上のような要求を満たす、新しいDAQソフトウェアの開発を行う。
1.3 本研究の目的
本研究の目的は、新検出器群FORESTに対して十分なデータ収集効率と柔軟性を持つDAQシステムを開発することである。ネットワーク分散型システムとなるDAQソフトウェアの設計を行い、データフローを管理するプロセスを実装した。また開発したDAQソフトウェアを用いて、加速器のビームを使った FORESTのデータ収集を行い、設計し実装したDAQシステムが FOREST実験において十分な性能があるかどうかの評価を行った。
10
第2章 FOREST実験で収集するデータ
DAQシステムのデータ収集効率は、1イベント当たりに収集するデータの大きさとデータ収集を行う頻度（トリガーレート）によって決定される。新しく DAQシステムを設計するにあたり、新検出器群FORESTを用いた実験で 1イベント当たりに収集するデータの大きさを見積もった。
2.1 データの大きさ
FOREST実験で収集する検出器のデータの種類は主として、
1. ガンマ線エネルギー標識化システム STB-Tagger II
2. 電磁カロリメータシステム FOREST
の 2種類のものに分類される。STB-Tagger IIは前後 116本の計 232本のシンチレーティングファイバーで構成され、制動放射でガンマ線を放出した反跳電子を検出する。反跳電子は通常の周回電子より運動量が低いので、STBリングを構成する偏向電磁石で運動量の大きさに応じて曲げられる。運動量分析された電子を偏向電磁石のヨークの隙間に設置した 4 mm角のシンチレーティングファイバーの前後 2本で検出することで、その電子の軌道を決定する。反跳電子の運動量と周回電子のエネルギーからガンマ線のエネルギーが決定される。STB-Tagger IIでは 116組のシンチレーティングファイバー前後 2本のコインシデンス信号の TDCデータのみを収集する。
FORESTは SCISSORS III、Backward Gamma、Rafflesia IIという 3つのガンマ線検出器と、それぞれの検出器用の荷電粒子識別用のプラスチックシンチレーターホドスコープから構成される。これらは各検出器ごとにエネルギー、タイミングを測定するので、ADCデータと TDCデータを収集する。FORESTを構成する検出器の数を表 2.1にまとめる。現在までに SCISSORS III、Backward Gammaが建設され、SCISSORS III用の荷電粒子識別用プラスチックシンチレーターホドスコープであるSPIDER、Backward Gamma用の荷電粒子識別プラスチックシンチレーターホドスコープである BGホドスコープがそれぞれに設置されている。
表 2.1: 検出器群 FORESTを構成する検出器数。（）付きの数字は建設を予定しているもので、現段階ではまだ建設が行われていない。
検出器群 構成検出器 個数SCISSORS III CsIクリスタル 192
SPIDER プラスチックシンチレータ 24（72）Backward Gamma Lead/SciFi 252BGホドスコープ プラスチックシンチレータ 12（18）
Rafflesia II Lead Glass （36）LGホドスコープ プラスチックシンチレータ （18）
SCISSORS IIIでは、SCISSORS IIのときに使用していた回路を継承し、TKO規格の ADC、TDCモジュールをデータ収集に使用する。TKO（Tristan/KEK Online） [5]は高エネルギー加速器研究機構
11
（KEK）がトリスタン実験用に開発したモジュールの規格でADCモジュールには豊伸電子社の 32チャンネルADC T004、TDCモジュールには林栄精器社の 16チャンネルTDC RPT-140を使用している。STB-Tagger IIのTDCデータもこのTKOのTDCモジュールで収集している。SPIDER用の信号は一時的にTKOのADC、TDCモジュールを用いて収集する。TKO規格のモジュールのADC、TDCデータはともに 32ビットを必要とする。
Backward Gammaはかつて大型放射光施設 SPring-8（Super Photon ring-8 GeV）の LEPS（Laser-Electron Photon Facility at SPring-8）実験で使用されていたものであり、そのとき使われていたCAMAC規格である FERAと呼ばれる高速読み出し可能なADCモジュールとVMEbus規格のUIOモジュールをデータ収集に用いる [6]。CAMAC（Computer Automated Measurement and Control）は計算機によるデータ収集及び制御を目的として規格化された I/Oバスで、広く原子核実験分野で使用されている。LeCroy社の 4300BというモデルのFERA（Fast Encording Readout ADC）はCAMAC規格のモジュールであるが、前面にあるデータ収集用のバス（FERAバス）を用いてVMEbus規格であるUIOモジュールでデータを収集する。VMEbus（VERSA Module Eurocard bus）は元々モトローラ社が 68000CPUのために開発したコンピューターバスで、現在では広く多くのデバイスで使用されている。UIO（UniversalI/O）はプログラマブルロジックデバイスを搭載している論理回路をユーザーが作成できるモジュールで、FERAドライバーを通して FERAバスのコントロールを行い FERAからデータを収集する。またTDCモジュールにはVMEbus規格でCAEN社の 128チャンネルTDC V1190A を使用する。これらのADCデータは 16ビット、TDCデータは 32ビットを必要とする。実際にデータ収集を行うときは、データの大きさを小さくするために、TDCデータは応答のあった検
出器のみのデータを収集する。また FERAモジュールにはペデスタルサブトラクションと呼ばれるペデスタル以上の値のデータのみを収集するような機能があり、それを用いて応答のあった検出器の ADCデータのみを収集する。FOREST実験において 1回のトリガーで応答のある検出器の平均的な数は、SCISSORS III、Backward Gammaでそれぞれ 10本程度であり、STB-Tagger II、SPIDER、BGホドスコープではそれぞれ数本程度であった。FERAでペデスタルサブトラクションを行ったときに収集されるデータは平均的に 25チャンネル程度であった。
TKO規格のモジュールで収集する SCISSORS IIIと STB-Tagger IIのデータの大きさは、ADCとTDCを合わせて約 250チャンネルで約 1キロバイトである。VMEbus規格のモジュールで収集するBackward Gammaのデータの大きさは、ADCが約 25チャンネルで約 50バイト、TDCが約 15チャンネルで約 60バイトである。FORESTの完成までに増加する検出器の数は 100程度であり、全ての検出器の ADC、TDCデータを 32ビットで読み出したとしても、増加するデータの大きさは最大で 800バイト程度である。以上のことから FOREST実験での 1つのイベントのデータの大きさは約 1～2キロバイトになると考えることができる。トリガーレートを 2 kHzとすると 1秒間で処理するバイト数は約 4メガバイト毎秒となり、初期のイー
サネットの通信速度である 10 Mbps（10メガビット毎秒）の速度では間に合わないようなデータ収集速度が FOREST実験では要求される。イーサネットとは一般的に使用されているコンピューターネットワークの規格のひとつで、現在では通信速度が 1 Gbps （1ギガビット毎秒）である 1000BASE-T/TXと呼ばれるギガビットイーサネットが普及しつつある。FORESTのデータ収集に用いるネットワークには、このギガビットイーサネットを使用する。
2.2 トリガー
FORESTで収集したいデータは、複数のガンマ線が検出器に入射したときのものである。ガンマ線は検出器に入射すると電磁シャワーを起こし、隣接する検出器に電磁シャワーが浸みだす。このため、1本のガンマ線に対して入射した検出器以外にも隣接する複数の検出器が応答する。そのため、応答した検出器のまとまりが 2つ以上あるときにデータ収集のトリガーを発生させるようにしたい。そこで
12
FORESTを構成する検出器群をいくつかのブロックに分割した。SCISSORS IIIを構成するCsIは、内側 1周分と外側 1周分の CsIをそれぞれ 1個のブロックとし、残りの CsIを 8個のブロックに分割している。Backward Gammaを構成する BGは、ϕ方向の 2列分である 14本の BG を 1個のブロックとして全部で 18個のブロックに分割している。図 2.1に SCISSORS IIIと Backward Gammaをブロックに分割した様子を示す。
図 2.1: SCISSORS IIIとBackward Gammaのブロック分割。SCISSORS IIIは太線で区切った 10個のブロックに分割されている。Backward Gammaは黒字と赤字で書かれた数字のまとまりがそれぞれ 1個のブロックになっていて、全部で 18個のブロックに分割されている。
CsIのBlock 1とBlock 10を除いたすべてのCsIのブロックとBGのブロックのうち 2個以上のブロックが応答したときにトリガー信号を発生させるようにした。この信号をNγ ≥ 2トリガーと呼ぶ。CsIのBlock 1と Block 10はそれぞれ内外に隣接する検出器がなく、電磁シャワーの浸みだしによって正しくエネルギーを測定することができないため、トリガーの作成に関与しないようにしている。Nγ ≥ 2トリガーでは 2個以上のブロックを突き抜けるような宇宙線でもトリガーがかかってしまい、収集するデータのバックグラウンドが増加する。トリガーにターゲットに入射したガンマ線によるイベントであることを要求するために、STB-Tagger IIの信号と Nγ ≥ 2 トリガーとのコインシデンスを取った信号を実際にデータ収集を行うトリガーとしている。STB-Tagger IIの信号と Nγ ≥ 2 トリガーとのコインシデンスは、
1. STB-Tagger IIの信号を ΣTaggerと呼ばれる 16個のブロックにまとめ、
2. 16個の ΣTagger信号とNγ ≥ 2トリガーでブロックごとのANDを取り、
3. ブロックごとのANDすべてのORを取る
という流れで行われる。この信号を ΣTagger ⊗ Nγトリガーと呼ぶ。STB Tagger IIの信号は応答するレートが高いため、すべての STB Tagger IIの信号のORを取った信号を作成すると、本来は別の信号であったものが結合して 1つの信号になってしまうことがある。これを避けるためにΣTaggerという複数のブロックの信号を作成し、先にその個々の信号とNγ ≥ 2トリガーとのANDを取ってからその後に全部のORを取るようにしている。図 2.2にトリガー作成の概略図を示す。
13
図 2.2: トリガーの概略図。SCISSORS IIを構成する検出器CsIのブロックCsI Block 2–9とBackwardGammaを構成する検出器 BGのブロック BG Block 1–18から Nγ ≥ 2となる信号を作成する。STB-Tagger IIを構成するシンチレーティングファーバーのブロック ΣTagger 1–16のそれぞれとNγ ≥ 2の信号のANDを取ったものすべてのORを取ってトリガーとした。
14
トリガーレートはターゲットの種類や大きさ、入射するガンマ線のビーム強度、トリガーの作成に参加させる検出器の数に大きく依存する。ガンマ線は加速器で加速周回されている電子にラジエーターをあてて制動放射を起こすことで得られるため、ラジエーターの挿入速度が一定ならば加速周回している電子の数が多いほど単位時間当たりのガンマ線の入射量は増加する。単位時間当たりのガンマ線の入射量が増加すればイベントが起こる確率が増加するので、トリガーレートが増加する。前方検出器であるSCISSORS IIIを用いてターゲットを炭素 10 mm、加速器のビーム強度を約 5mAとしたときにトリガーレートは約 2 kHz程であった。FOREST実験では数 kHzのオーダーでのデータ収集を考えている。
15
第3章 DAQソフトウェアの設計
FORESTのDAQシステムをネットワーク分散型のシステムとするDAQソフトウェアの設計を行った。物理実験における多くのDAQシステムはネットワークを使用したネットワーク分散型のシステムである [7, 8]。一般にDAQシステムの開発には多くの時間がかかるため、汎用性のあるDAQソフトウェアが求められる [9]。FORESTのDAQシステムとして、FORESTの拡張性や実験状況の変化に容易に対応できるようなDAQソフトウェアの設計を目指した。
3.1 ネットワーク分散型システム
大型の検出器になるほどそれを構成するひとつひとつの検出器の数が増加し、読み出すADC、TDCのチャンネルの数が増加する。同じ種類、同じ規格のモジュールではデジタル化したデータの読み出しにかかる時間は読み出すチャンネル数にほぼ比例するから、単純に 1台のパソコンでデータ収集を行うとすれば、読み出すデータ数に応じてデータ収集効率は低下することになる。FORESTで 1イベント当たりに収集するデータの大きさは § 2で述べたように SCISSORS IIのときと比較すると 2倍以上になっており、トリガーレートも検出器が覆う立体角が大きくなるため増加する。そこで、複数のサブシステム（コレクター）を用意してデータの読み出しを並列的に行う DAQシステムを設計することにした。これによって、エネルギーやタイミングを測定する検出器群の追加やデータを読み出すハードウェアモジュールの変更に対して、コレクターの追加または変更を行うことで全体のDAQシステムに大幅な変更を加える必要がなくなる。複数のコレクターでデータを収集するため、それぞれのコレクターが収集するデータはそれらすべて
で 1つの物理事象（イベント）をあらわすデータとなる。従って、コレクターで収集したデータをイベントに構築するプロセス（イベントビルダー）が必要となる。さらにサブシステムが増加していくとイベント構築に負荷がかかることが予想できるため、データをファイルに書き出すプロセス（レコーダー）を別途用意する。またデータの収集および収集したデータの記録を行う実験者（ユーザー）がこれらのプロセスやデータを監視または制御するためのコントローラー、モニター（オンラインモニター）もプロセスとして必要である。コレクター、イベントビルダー、レコーダー、コントローラー、オンラインモニターといったプロセ
スをネットワーク上に分散させてデータ収集を行うシステムを設計した。それぞれのプロセスの接続にはネットワークを用いる。ネットワークは物理実験分野においても広く普及しており、特別な機器を必要とせず簡単に構築することができる。それぞれのプロセスは同一のネットワークに配置せず、次のように 3つのネットワークを切り分けた。
1. コレクターとイベントビルダー
2. イベントビルダーとレコーダー
3. コントローラー、モニターとイベントビルダー
コレクターからイベントビルダー、イベントビルダーからレコーダーはデータの流れが集中するため、それぞれを専用のネットワークを構成することでネットワークにかかる負荷を分散する。さらにコントロール、モニター用のネットワークを別のネットワークとして構成することで、データ収集、記録のた
16
めのネットワークの負荷を軽減させる。イベントビルダーは 3つのネットワークに接続し、それぞれのネットワーク上にあるプロセスはイベントビルダーを通してデータ、コマンド、ログのやり取りを行う。図 3.1にネットワーク上にネットワークごと分散されたプロセスの様子を示す。
図 3.1: ネットワーク上に分散されたプロセスの様子。イベントビルダーを中心に 3つのネットワークに分散されている。ネットワーク上に分散したプロセス間のデータ、コマンド、ログの流れをそれぞれ青色、緑色、赤色の矢印で示した。
ネットワーク分散型のシステムであるDAQシステムでは、ネットワークに分散したプロセス間のデータ、各プロセスの動作をコントロールするコマンド、各プロセスの動作状況を閲覧するログを管理する必要がある。図 3.1ではデータ、コマンド、ログの流れが混在してしまい、効率良く管理を行うことが難しい。そこでデータ、コマンド、ログの流れをそれぞれ次の 3つのレイヤーに分割することで効率良く管理を行うようにした。
1. データの流れを管理するデータフローレイヤー
2. プロセス間のコマンドを管理するプロセス管理レイヤー
3. プロセスのログを管理するログ管理レイヤー
それぞれのレイヤーにおいて必要となるプロセスの動作を考察し、それぞれのレイヤーごとにDAQソフトウェアの開発を行う。データフローレイヤーでは、コレクター（Col）、イベントビルダー（EB）、レコーダー（Rec）、オンラインモニター（Mon）によってデータの流れの管理を行う。プロセス管理レイヤーでは、プロセスマネージャー（PM）、プロセスマネージャーゲートウェイ（PMGW）、プロセスコントローラー（P-Ctrl）によってプロセスのコマンド制御を行う。ログ管理レイヤーでは、ログウォッチャー（LW）、ログウォッチャーゲートウェイ（LWGW）、ログモニター（LM）によってログの管理を行う。図 3.2にDAQソフトウェアのレイヤー構造を示す。
3.2 データフローレイヤー
データフローレイヤーは、DAQシステムで最も重要となるデジタル化したデータの流れを管理するレイヤーである。データフローレイヤーでは次の 4つのプロセスでデータの流れの管理を行う。
17
図 3.2: DAQソフトウェアのレイヤー構造。上から順にデータフローレイヤー、プロセス管理レイヤー、ログ管理レイヤーをあらわす。それぞれのレイヤーで管理されるデータ、コマンド、ログの流れを矢印で示している。
18
1. コレクター（Collector）
2. イベントビルダー（Event Builder）
3. レコーダー（Recorder）
4. オンラインモニター（Online Monitor）
図 3.3にデータフローレイヤーの概観図を示す。
図 3.3: データフローレイヤーの概観図。コレクターからイベントビルダーに送信されるデータは、イベントビルダーで構築されるデータ（Data）に対してフラグメント（Fragment）と呼んでいる。
コレクターはデータの収集を行うプロセスである。ハードウェアからデータを読み出し、イベントビルダーに送信する。コレクターは必要な数だけ自由に開発することができる。イベントビルダーはデータの構築を行うプロセスである。複数のコレクターから送信されたデータを 1つのイベントとして構築し、レコーダーに送信する。またオンラインモニターにもデータを送信する。レコーダーはデータの記録を行うプロセスである。イベントビルダーから送信されたデータをハードディスクに保存する。オンラインモニターはデータの表示を行うプロセスである。イベントビルダーから送信されたデータをリアルタイムで解析して表示する。各プロセスの詳細は § 4で述べる。コレクターからイベントビルダー、イベントビルダーからレコーダーにはデータの流れが集中するた
め、大量のデータが流れてもネットワークがつまらないようにそれぞれのネットワークを切り分けている。さらにイベントビルダーとオンラインモニターの接続するネットワークも別のネットワークを構成した。イベントビルダーは 3つのネットワークに接続している。
3.2.1 通信方法
データフローレイヤーでは、コレクターとイベントビルダー、イベントビルダーとレコーダーの通信をTCPで行う。TCP（Transmission Control Protocol） [10]はOSI参照モデルのトランスポート層にある通信プロトコルである。OSI（Open System Interconnection）参照モデルとは、通信機能やプロトコルを階層的に分割したモデルで、物理層、データリンク層、ネットワーク層、トランスポート層、その上の上位層から構成される。プロトコルとは、ネットワークを介してコンピューター同士が通信を行う上で相互に決められた規約のことである。TCPはコネクション指向のプロトコルであり、通信の信頼性が保証される。TCPでは、
1. 送信先が存在することを確認する
19
2. 送信先がデータを受信したことを確認する
3. 送信先にデータが届かなかったときに再送信を行う
4. データが大きいときに分割して送信する
5. 送信されたデータの順序の保持する
以上のことを行って確実性のある通信を行う。DAQシステムにおいてデータを正しく収集して記録することは重要なことである。コレクターからレコーダーまで確実にデータを送信して記録するために通信には TCPを用いた。イベントビルダーからオンラインモニターの間の通信にはUDPのマルチキャストという通信方式を用
いて行った。UDP（User Datagram Protocol） [11]は、TCPと同様にOSI参照モデルのトランスポート層にある通信プロトコルである。UDPはコレクションレス指向のプロトコルであり、TCPと違って通信の信頼性は保証されない。UDPでは、
1. 送信先にデータが届いたか確認しない
2. 途中でデータが紛失される可能性がある
3. データの到着順が保証されない
といった点で TCPと異なる。UDPは TCPと比べて不確実ではあるが、実装が容易であること、送受信にかかる処理が少ないことが利点としてあげることができる。オンラインモニターでは収集している一部のデータを受信して表示することで問題ないため、イベントビルダーの負荷を軽減させるために通信には TCPではなくUDPを用いた。マルチキャストについては § 4.2.3で詳しく述べる。
3.3 プロセス管理レイヤー
プロセス管理レイヤーは、ネットワーク上に分散したプロセスの管理を行うレイヤーである。プロセス管理レイヤーでは次の 3つのプロセスでプロセス間のコマンドの流れの管理を行う。
1. プロセスマネージャー（PM）
2. プロセスマネージャーゲートウェイ（Gateway）
3. プロセスコントローラー (Process Controller)
図 3.5にプロセス管理レイヤーの概観図を示す。ネットワーク分散型のシステムでは複数のプロセスが複数のパソコン上で動作する。これらのプロセ
スを手動で管理しようとすれば、プロセスの起動や終了のたびにそのプロセスが動作しているパソコンにログインしなければならない。これを回避するため、ユーザーが操作できる 1台のパソコンからすべてのプロセスを制御できる仕組みが必要となり、プロセス管理レイヤーを設計した。プロセス管理レイヤーでは、プロセスの起動や終了のほかにデータ収集のランの開始や停止といったコマンドの制御を行う。
3.3.1 プロセスマネージャー
プロセスマネージャーは、DAQシステムのプロセスが実行されるすべてのパソコンで動作し、そのパソコン上のプロセスの起動や終了といったコマンド制御を行うプロセスである。プロセスマネージャーはパソコンの起動とともにデーモンとして自動的に起動するようにしておく。デーモンとはUNIX系のOSでバックグラウンドで動作をするプロセスのことをいう。
20
図 3.4: プロセス管理レイヤーの概観図。プロセスコントローラー（Process Controller）からのコマンドはプロセスマネージャーゲートウェイ（Gateway）によって別のネットワーク上にあるプロセスマネージャー（PM）まで送信される。コマンドを受信したプロセスマネージャーがプロセスのコマンド制御を行う。
プロセス管理
プロセスマネージャーは同じパソコン上で動作しているプロセスへのコマンドを管理する。ユーザーが操作するプロセスコントローラーからプロセスへのコマンドを受信し、プロセスへそのコマンドを伝送する。プロセスマネージャーからプロセスへのコマンドの伝送方法としてシグナルと共有メモリ（SharedMemory）を利用する方法を考えている。シグナルとは実行中のプロセスに外部から割り込んで別の処理を行わせることができる機構で、共有メモリとは複数のプロセスがアクセスすることのできるメモリ空間のことである。プロセスマネジャーからプロセスへのコマンドは、
1. プロセスマネージャーがプロセスコントローラーからコマンドを受信する
2. プロセスマネージャーがコマンドを共有メモリに書き込む
3. プロセスマネージャーがプロセスにシグナルを送る
4. シグナルを受け取ったプロセスが共有メモリにアクセスしてコマンドを読み取る
という流れで行う。図 3.5にプロセスマネージャーによるプロセスのコマンド制御の様子を示す。
3.3.2 プロセスマネージャーゲートウェイ
プロセスマネージャーゲートウェイは、プロセスコントローラーとネットワークが異なるプロセスマネージャーとの間で通信ができるようにするためのプロセスである。ふつう互いに異なるネットワーク
21
図 3.5: プロセスマネージャーからプロセスへのコマンド制御の様子。プロセスマネージャーはコマンド内容を共有メモリ（Shared Memory）に書き込んでからプロセスにシグナルを送る。シグナルを受け取ったプロセスは共有メモリにアクセスしてコマンドを読み取る。
上にあるパソコン同士では通信を行うことができない。設計するDAQシステムはネットワークの負荷を分散するため、コレクターとイベントビルダーを接続するコレクター用ネットワーク、イベントビルダーとレコーダーを接続するレコーダー用ネットワーク、イベントビルダーとコントローラー、モニターを接続するモニター用ネットワークがイベントビルダーを中心として分離されている。プロセスコントローラーはモニター用ネットワークに位置するため、このままだとコレクター、レコーダーが接続しているネットワークにあるプロセスマネージャーと通信を行うことができない。そこで、あるネットワークにあるパソコンから別のネットワークにあるパソコンへとコマンドを転送することができるプロセスが必要である。プロセスマネージャーゲートウェイは、すべてのネットワークに接続しているイベントビルダーが動作しているパソコン上で動作し、別個のネットワーク上にあるプロセスからのコマンドやデータの通信の制御を行う。プロセス管理レイヤーで送受信されるパケットに送信先の IPアドレスを明記することで、プロセス
マネージャーゲートウェイはその IPアドレスが存在するネットワークにパケットを送信する。
3.3.3 プロセスコントローラー
プロセスコントローラーは、プロセスマネージャーを介してコレクターやイベントビルダー等のプロセスにコマンドを送信するプロセスである。ユーザーはプロセスコントローラーでプロセスのコマンド制御を行う。プロセスコントローラーは、プロセスマネージャーにコマンドを送信する。同じネットワーク上のプロセスマネージャーには直接、異なるネットワーク上のプロセスマネージャーにはプロセスマネージャーゲートウェイを通してコマンドを送信する。
22
3.3.4 通信方法
プロセス管理レイヤーでは、各プロセス間の通信を UDPで行う。データが正しく送受信されたかを保証するために様々な処理を行うTCPにくらべて、UDPはそれを保証しないのでネットワークにかかる負荷が少ない。データフローレイヤーでのデータの流れを優先するためにプロセス管理レイヤーでの通信はUDPを用いる。UDPで通信を行うため、コマンドが正しく送受信されたかどうかの確認は各プロセスが行う。UDPではデータが途中で紛失する可能性があるため、プロセス管理レイヤーのプロセスには次のような機能を持たせる必要がある。
1. 送受信したコマンドの履歴の保持する
2. コマンド受信時に送信元へリプライを送信する
3. リプライがない時にコマンドを再送信する
プロセスコントローラーは、プロセスマネージャーにコマンドを送信してもしリプライがなければもう一度コマンドを送信する。プロセスマネージャーは、コマンドは受信したがリプライがプロセスコントローラーに届かなかったためにコマンドが再送されてくる場合もありうるので、コマンドの履歴を管理しプロセスの二重起動等が起こらないようにする。
3.4 ログ管理レイヤー
ログ管理レイヤーは、ネットワーク上に分散したプロセスのログの管理を行うレイヤーである。ログ管理レイヤーでは次の 3つのプロセスでプロセスのログの管理を行う。
1. ログウォッチャー（Log Watcher）
2. ログウォッチャーゲートウェイ（LW Gateway）
3. ログモニター（Log Monitor）
図 3.6にログ管理レイヤーの概観図を示す。ネットワーク分散型のシステムでは複数のプロセスが複数のパソコン上で動作する。各プロセスの動
作状況を監視することはDAQシステムを管理する上で必要なことである。プロセスはネットワーク上に分散しているので、単純に各プロセスのログを画面に表示させるまたはファイルに書き出すといった方法では簡単にモニターすることができない。そこで、ユーザーがモニターできる 1台のパソコンでプロセスのログを一括して管理する仕組みが必要となり、ログ管理レイヤーを設計した。
3.4.1 ログウォッチャー
ログウォッチャーは、DAQシステムのプロセスが実行されるすべてのパソコン上で動作し、そのパソコン上のプロセスのログを管理するプロセスである。すべてのプロセスはログをファイルに書き出すようにしておく。ログウォッチャーはそのログ情報が書き出されたファイルを監視し、ログモニターにログ情報を送信する。図 3.7にログウォッチャーの概略図を示す。
23
図 3.6: ログ管理レイヤーの概略図。各プロセスのログはログウォッチャー（LM）からログゲートウェイ（LW Gateway）によって別のネットワーク上にあるログモニター（Log Monitor）まで送信される。
図 3.7: ログウォッチャーの概略図。プロセスはログをファイルに書き出す。ログウォッチャーはそのファイルを読んでログをログモニターまで送信する。
24
3.4.2 ログウォッチャーゲートウェイ
プロセス管理レイヤーと同様、ログモニターとは別のネットワークにあるパソコン上で動作しているプロセスのログをログモニターまで送信するための仕組みが必要である。ログウォッチャーゲートウェイはすべてのネットワークに接続しているイベントビルダーが動作しているパソコン上で動作し、あるネットワークから別のネットワークへのログデータの転送を行う。プロセスマネージャーゲートウェイ同様、ログウォッチャーゲートウェイは別個のネットワークに接続しているログモニターとログウォッチャーとの通信の管理を行う。
3.4.3 ログモニター
ログモニターは、DAQシステム内のすべてのプロセスのログを管理して表示するプロセスである。ユーザーのコマンドによってログをログウォッチャーから受信し、ログを画面に表示またはファイルに保存する。ログデータの通信方法にはTCPを想定している。ログデータを一括してログウォッチャーからログモニターへ送信することを考えると、途中でデータが損失する可能性のある UDPでは危険があるからである。ネットワークへの負荷を軽減するため、ユーザーからのコマンドがあったときのみTCPの接続を確立してデータを受信するようにする。
25
第4章 データフローを管理するプロセスの実装
設計したDAQソフトウェアは、データフローレイヤー、プロセス管理レイヤー、ログ管理レイヤーと呼ぶ 3つのレイヤーで構成されている。データフローレイヤーでは、次の 4つのプロセスでデータの流れを管理する。
1. コレクター
2. イベントビルダー
3. レコーダー
4. オンラインモニター
これらのプロセスの実装を C言語を用いて行った。本来データフローレイヤーのプロセスはデータの管理のみを行い、プロセスの制御やコマンドの管理
は行わない。しかしながらプロセスの開発段階においてはデータフローレイヤーのプロセスのみでも実際の実験状況でデータ収集を行えるようにする必要があった。このため、プロセス管理レイヤーが行う処理の代替処理として、コレクター、イベントビルダー、レコーダーは各プロセス間で最低限のプロセス制御ができるようにコマンドを通信する機能を実装している。
4.1 コレクター
コレクターは、ADCモジュールやTDCモジュール等のハードウェアからデータを収集し、収集したデータを 1イベントずつイベントビルダーに送信するプロセスである。コレクターは実験状況に応じて複数用意することができる。ハードウェアからデータの読み出しを複数のコレクターで並列的に行うことで、データの読み出しにかかる負荷を分散させる。複数のコレクターで収集したデータは、イベントビルダーで 1つのイベントのデータとして構築される。図 4.1にコレクターの概観図を示す。
4.1.1 コレクターでの処理
コレクターはデータ収集時に次の 3つの処理をマルチスレッドで行う。
1. ハードウェアからデータを読み出す（データ収集スレッド）
2. イベントビルダーへデータを送信する（データ送信スレッド）
3. イベントビルダーからコマンドを受信する（コマンド受信スレッド）
図 4.2にコレクターのマルチスレッドの様子を示す。マルチスレッドとは、1つのプロセス内にスレッドと呼ばれる処理単位を複数生成し、並行して処理
を行う機能である。コレクターをマルチスレッドにすることによって、次のような利点がある。
26
図 4.1: コレクターの概観図。データとコマンドの流れをそれぞれ青色の実線と緑色の点線の矢印で示している。コレクターはハードウェアからデータを読み出し、イベントビルダーに送信する。複数のコレクターで収集されたデータはイベントビルダーで 1つのデータに構築される。
図 4.2: コレクターのマルチスレッド。データ収集（Collect Data）、データ送信（Send Data）、コマンド受信（Receive Command）の処理をマルチスレッドで並列して行う。
27
1. データの収集とデータの送信を並列処理にすることで、ネットワークがつまってデータの送信ができないときにデータの収集を行うことができ、トリガーの発生待ちでデータの収集をしていないときにデータの送信を行うことができる。これによりシングルスレッドとしたときよりも効率良く処理を行うことができる。
2. スピル構造を持つ加速器による実験では、ビームが出る時間と出ない時間が周期的に切り替わる。ビームが出てイベントが発生している間はデータの収集に専念し、ビームが出ずイベントが発生しない間にデータの送信を行うようにできると効率的である。マルチスレッドではどのスレッドの処理を優先的に行うかを調整することが出来る。スレッドのコントロール機能を実装することで、データ収集の処理とデータ送信の処理の効率的な切替を実験状況に応じて行うことが可能となる。
3. データ収集のランの開始や停止といったコマンドはユーザーが任意に行うため、シングルスレッドとすると定期的にコマンドを確認するような処理が必要となる。コマンドを受信する処理をスレッドとしてデータ収集、データ送信から切り分けることで処理の流れを簡略化している。
同様な並列処理は、コレクターをマルチプロセスとすることでも実現可能である。プロセスは各プロセスごとにデータ領域を確保するため、データ収集プロセスとデータ送信プロセスで同じデータを共有するためには、何かしらのプロセス間通信を行わなければならない。スレッドは同一プロセス内で処理を行うため、同一のデータ領域を使用することができる。プロセス間通信を用いるよりも同一プロセス内でデータ領域を参照するほうが処理がはやいため、コレクターではマルチスレッドを採用した。図 4.3にマルチプロセスとマルチスレッドの概念図を示す。
図 4.3: マルチプロセスとマルチスレッドの概念図。プロセスはそれぞれが独立したデータ領域を持つ。マルチスレッドではスレッド同士でデータ領域を共有できるが、マルチプロセスでは共有できないため、データのやり取りはプロセス間通信を行う必要がある。
データ収集スレッド
データ収集スレッドでは、ハードウェアからデータを読み出し、共有バッファに書き込む処理を行う。共有バッファとはデータ収集スレッドとデータ送信スレッドが互いに読み書きすることができるバッファ
28
であり、§ 4.1.3で詳しく述べる。データ収集スレッドはデータ収集のランの開始のコマンドとともに作成され、ランの停止のコマンドがあるまでデータ収集を繰り返す。共有バッファが一杯であれば、データ送信スレッドでデータの送信があるまで待機する。データ収集スレッドで行われる処理はユーザーが実装する。
データ送信スレッド
データ送信スレッドでは、共有バッファからデータを読み出し、イベントビルダーに送信する処理を行う。データ送信スレッドは、共有バッファから読み出したデータにイベントビルダーやオンラインモニターでデータを識別するためのコレクターナンバー、イベントナンバー、ランナンバーを先頭に付け、パケットと呼ぶ形式にしてイベントビルダーに送信する。パケット等のデータフォーマットについては§ 4.6 で詳しく述べる。データ送信スレッドはデータ収集のラン開始のコマンドとともに作成され、ランの停止のコマンドがあるまでデータ送信を繰り返す。共有バッファが空であれば、データ収集スレッドで読み出したデータの書き込みがあるまで待機する。
コマンド受信スレッド
コマンド受信スレッドでは、イベントビルダーと接続しているソケットを常に監視し、イベントビルダーからコマンドを受信して処理を行う。ソケットとはネットワークアドレスのことで、TCPでは IPアドレスとポート番号の組になっている。IPアドレスはネットワーク上のコンピューターの 1つを指定するもので、ポート番号はそのコンピューター上で動作している複数のプロセスの 1つを指定するために用いる。イベントビルダーから送信されるコマンドには次の 3種類がある。
1. 「START」コマンド。データ収集スレッドとデータ送信スレッドを作成してデータ収集のランを開始する。「STOP」のコマンドがあるまでデータ収集スレッドとデータ送信スレッドはそれぞれの処理を続ける。
2. 「STOP」コマンド。データ収集スレッドとデータ送信スレッドを終了させてデータ収集のランを停止する。データ送信スレッドはバッファに蓄積されているデータを全部送信した後に終了するようにした。データ送信の最後としてイベントビルダーにコレクターヘッダを送信する。ヘッダの形式については § 4.6.2 で詳しく述べる。
3. 「EXIT」コマンド。イベントビルダーとの接続を切断し、プロセスを終了する。
コマンド受信スレッドで行われる処理は、本来はプロセス管理レイヤーのプロセスマネージャーからのソフトウェア割り込みによって行われる。プロセスマネージャーからのソフトウェア割り込みの代替処理として、イベントビルダーがコレクターへネットワークを通してコマンドを送信している。
4.1.2 ユーザーが実装する処理
コレクターは実験状況や使用するハードウェアモジュールによってユーザーが実装する。コレクターの実装を容易にするため、コレクターの処理はフレームワークとしてユーザーに提供される部分と、ユーザーが実装する部分に分離されている。フレームワーク部分では、イベントビルダーへの接続やデータの送信といったすべてのコレクターで共通の処理を行う。ユーザー実装部分は次の 5つの処理で構成される。
29
UserInit 初期化処理。コレクターを起動したときに行う処理で、ハードウェアに必要なパラメータファイルの読み込み等の処理を行う。ユーザーは共有バッファの大きさと数を設定することができ、ハードウェアから読み出すデータの大きさに応じて共有バッファの大きさと数をこの処理の中で指定する。
UserStart ラン開始処理。データ収集のランが開始したときに行う処理で、使用するハードウェアの初期化等の処理を行う。
UserDAQ データ収集処理。データ収集スレッドで行う処理で、ハードウェアからデータを読み出し、共有バッファに書き込む処理を行う。共有バッファはUserInit処理での指定に従ってフレームワーク部分で作成される。共有バッファへの書き込みにはライブラリを用意し、ユーザーが簡単に行えるようにした。
UserStop ラン停止処理。データ収集のランが停止したときに行う処理で、ハードウェアのバッファのクリア等の処理を行う。
UserFinal 終了処理。コレクターを終了するときに行う処理で、使用していたハードウェアへのアクセスをクローズする等の処理を行う。
図 4.4にコレクターの処理の流れの中にユーザーが実装する処理がどのタイミングで行われるかを示した。
図 4.4: コレクターの処理の流れ。処理の流れの中にユーザーが実装する処理が行われるタイミングを示してある。
30
4.1.3 バッファハンドリング
コレクターはデータの収集とデータの送信をマルチスレッドで並列して処理を行うため、データ収集スレッドで収集したデータはただちにデータ送信スレッドで送信されるとは限らない。このため、データ収集スレッドで収集したデータをデータ送信スレッドでの送信が完了するまで管理しておくバッファが必要である。このバッファを共有バッファと呼ぶ。データ収集スレッドで共有バッファに書き込まれたデータは書き込まれた順にデータ送信スレッドで読み出されて送信される。図 4.5に共有バッファの概念図を示す。
図 4.5: 共有バッファの概念図。共有バッファでは、データは書き込まれた順に読み出されるようにしている。
共有バッファの構造
イベントビルダーは 1イベントごとにデータをイベントとして構築するため、コレクターは 1イベントずつデータをイベントビルダーに送信しなければならない。コレクターの開発当初は、データ収集スレッドは 1イベント分のデータを共有バッファに書き込み、データ送信スレッドはその 1イベント分のデータを読み出して送信するようにしていた。しかしながらこの方法では、ハードウェアから複数イベント分のデータをまとめて読み出すようにしたときに不都合が生じた。ハードウェアモジュールには内部にバッファを持ち、複数イベント分のデータを蓄積しておくことのできるものがある。この機能によってハードウェアからパソコンへのデータの読み出し回数を減らし、データ処理にかかる時間を短縮することができる。共有バッファには 1イベントずつ書き込むため、ハードウェアから読み出す複数イベント分のデータを直接共有バッファに書き込むことができず、一度パソコン上のメモリに読み込んでから1イベントずつ切り出して共有バッファに書き込まなければならない。ハードウェアからデータ収集スレッドで使用しているメモリ、データ収集スレッドで使用しているメモリから共有バッファへと、メモリコピーを 2回行うので処理に時間がかかってしまう。図 4.6にハードウェアから読み込んだ複数イベント分のデータを 1イベントずつに切り分けてバッファに書き込む様子を示す。ハードウェアから読み出すデータが複数イベント分のデータになっても直接共有バッファに書き込め
るように、共有バッファを次のような構造にした。共有バッファは、
31
図 4.6: 複数イベント分のデータのバッファリングの様子。複数イベントのデータを 1イベントずつに切り分けてバッファに書き込むため、2回メモリコピーを行うことになって処理に時間がかかる。
1. ハードウェアから読み込んだデータを直接書き込むバッファ（データバッファ）
2. データを 1イベントごとに分割するための先頭アドレスとデータの大きさを書き込んでおくバッファ（ポインタバッファ）
から構成される。データバッファには複数イベントでも構わずハードウェアから読み込んだデータを直接書き込む。このままではデータ送信スレッド側ではデータバッファに書き込まれたデータが何イベント分のデータなのか、複数イベント分のデータならイベントごとの切れ目はどこにあるのかを知ることができない。そこでポインタバッファに各イベントのデータの先頭アドレスとデータの大きさをイベントの数だけ書き込んでおく。データ送信スレッドはポインタバッファに書き込まれたデータの先頭アドレスと大きさを読み取ることで、データバッファに書き込まれたデータから 1イベントずつデータをイベントビルダーに送信することができる。図 4.7に共有バッファの構造を示す。
排他制御
共有バッファにはデータ収集スレッドによるデータの書き込みとデータ送信スレッドによるデータの読み出しが行われる。マルチスレッドによるこの 2つの処理は同期していないため、共有バッファに対して処理を同時に行わないように排他制御を行う必要がある。このような処理が必要な部分をクリティカルセクションと呼ぶ。図 4.8にクリティカルセクションの例を示す。図 4.8はある値Xを 1増やす処理を同期せずにほぼ同時に 2回行ったときに起こりうる処理の流れである。片方の処理がXの値を読み込んでから書き換え終わる前にもう一方の処理がXの値を読み込んでしまい、処理が 2回行われたにも関わらずXの値は 1しか増えていないという意図しない結果となっている。共有バッファはデータ収集スレッドとデータ送信スレッドから同時にアクセスされる可能性のあるク
リティカルセクションであるため、Mutexと呼ばれる同期変数を用いて排他制御を行った。Mutexには
32
図 4.7: 共有バッファの構造。共有バッファはハードウェアから読み込んだデータを書き込むためのバッファと 1イベントごとに切り分けるための各イベントの先頭アドレスとデータの大きさを書き込んでおくバッファから構成されている。
図 4.8: クリティカルセクションの例。処理（A）がXの値を読み込み（1）、処理（A）がXの値を 1増やして書き換える前に処理（B）がXの値を読み込む（2）。この時点ではまだXの値は 0のままである。処理（A）はXの値を 1増やしてX = 1としてXの値を書き換えたにも関わらず（3）、処理（B）はそれに気付かずに処理（B）が読み込んだ時点でのXの値を 1増加させるので、X = 1としてXの値を書き換える（4）。処理（A）と処理（B）で 2回の処理を行ったのに対して Xの値は 2増えず 1しか増えていない。このような問題が起こりうる部分のことをクリティカルセクションという。
33
ロックとアンロックという 2つの操作がある。あるスレッドが最初にMutexをロックすると、別のスレッドがそのMutexをロックしようとしたときにそのMutexがアンロックされるまで処理を停止させることができる。Mutexをロックしていた処理がMutexをアンロックすると、そのMutexをロックしようとして処理が停止していたスレッドがMutexをロックできるようになり、Mutexをロックして処理を行う。共有バッファのアクセスにMutexを使用することで、データ収集スレッドとデータ送信スレッドの排他制御を行った。図 4.9にMutexを用いた処理の流れを示す。
図 4.9: Mutexを用いた処理の流れ。データ収集スレッドが最初にMutexをロックする（1）。データ送信スレッドは共有バッファにアクセスするためにMutexをロックしようとするが、Mutexはデータ収集スレッドでロックされているためにアンロックされるまで待つことになる（2）。データ収集スレッドは共有バッファへのデータの書き込みを終えると（3）、Mutexをアンロックする（4）。今度はデータ送信スレッドがアンロックされたMutexをロックして（5）、共有バッファからデータの読み出しを行い（6）、処理が終わるとMutexをアンロックする（7）。このようにして 2つのスレッドが同時に共有バッファへアクセスしてしまうことを防いでいる。
4.1.4 スローコレクター
スローコレクターは、毎イベント必ずしも収集しなくてよいデータを収集することができるコレクターである。通常のコレクターで収集されたデータは必ずイベントとしてイベントビルダーで 1つのデータに構築される。それに対してスローコレクターで収集されたデータはそのデータが収集されたときのみイベントビルダーでイベントの一部として構築される。イベントビルダーは通常のコレクターからのデータは必ずイベントとして構築し、スローコレクターからのデータはそれがあったときのみ他のコレクターのデータと一緒に構築する。スローコレクターによって、毎イベント必要な検出器のADC、TDCといったデータ以外のデータを収集することができる。具体的には、
1. 一定時間間隔のターゲットの温度情報
2. スピルごとのトリガー発生数等のスケーラー情報
34
といった毎イベントでなくてよいデータをスローコレクターで収集する。またデータ収集のランに関する情報をスローコレクターのデータとしてイベントビルダーに送信すれば、データと同じファイルにランに関する情報を記録しておくことができる。データと同じファイルに記録しておきたい情報としては、核理研ではデータ収集時の加速器の運転パターンやラジエーターの運転パラメーターといったものがある。図 4.10にスローコレクターの概念図を示す。
図 4.10: スローコレクターの概念図。通常のトリガーで収集するコレクターのデータとは別に、他のイベントと同期させる必要のないデータをスローコレクターで収集することができる。
スローコレクターと通常のコレクターとの違いはイベントビルダーでデータの扱いが異なるだけで、他はすべて同じである。スローコレクターは通常のコレクターと同じように実装でき、起動時に読み込む設定ファイルでスローコレクターとすることができる。
4.1.5 デモコレクター
通常コレクターは起動するとイベントビルダーに接続し、イベントビルダーもしくはプロセスマネージャーからのコマンドによってデータの収集の開始や停止を行う。§ 4.1.2で述べたように、コレクターの開発においてハードウェアからデータを収集するために必要な処理はユーザーが実装する。ユーザーが実装した処理をテストするためにイベントビルダーやプロセスマネージャーを用意しなければならないのは不便であるため、コレクターが単体でデータ収集を実行できるような機能を実装した。この機能をデモコレクターと呼ぶ。コレクターは起動時に通常のコレクターとして起動するかデモコレクターとして起動するかを引数で指定することができる。コレクターをデモコレクターとして実行すると、
1. イベントビルダ－に接続せず、収集したデータをイベントビルダーに送信するかわりにファイルに書き出す
2. イベントビルダーやプロセスマネージャーからのコマンドを必要とせず、実行と同時にデータ収集を開始する
35
ようになる。図 4.11にデモコレクターの概観図を示す。
図 4.11: デモコレクターの概観図。デモコレクターは収集したデータをイベントビルダーに送信するかわりにファイルに書き出す。それ以外は通常のコレクターと同じ処理を行う。
デモコレクターにはデータ収集のランの開始、停止といったコマンドはないため、デモコレクターの実行時に引数として収集するイベント数を指定するようにした。デモコレクターは実行と同時にデータ収集を開始し、指定されたイベント数のデータを収集したら終了する。図 4.12にデモコレクターの処理の流れを示す。デモコレクターはイベントビルダーにデータを送信しないため、デモコレクターとして実行すること
によってコレクター単体のデータ収集効率を測定することができる。§ 5ではデモコレクターとして実行したときとイベントビルダーに接続してデータの送信を行う通常のコレクターとして実行したときのデータ収集効率を比較することでイベントビルダーがデータ収集効率の律速となっているかどうかを調べた。
4.2 イベントビルダー
イベントビルダーは、複数のコレクターから送信されたデータ（フラグメントデータ）を受信し、受信したフラグメントデータを 1つのイベント（イベントデータ）に構築し、構築したイベントデータをレコーダーとオンラインモニターに送信するプロセスである。図 4.13にイベントビルダーの概観図を示す。
4.2.1 イベントビルダーの処理
イベントビルダーはデータ収集時に次の 4つの処理をマルチスレッドで行う。
1. コレクターからフラグメントデータを受信する（データ受信スレッド）
2. コレクターから受信したデータをイベントデータに構築する（イベント構築スレッド）
3. レコーダーとオンラインモニターへイベントデータを送信する（データ送信スレッド）
36
図 4.12: デモコレクターの処理の流れ。デモコレクターでは起動すると同時にデータ収集のランを開始してデータを収集し、データの収集が終わるとランを停止して終了する。ユーザーが実装する処理は通常のコレクターとして起動したときと同じように行われる。
図 4.13: イベントビルダーの概観図。データとコマンドの流れをそれぞれ青色の実線と緑色の点線の矢印で示している。コレクターから送信されるデータをフラグメントデータ（Fragment）イベントビルダーで構築されてレコーダーとオンラインモニターに送信するデータをイベントデータ（Event）と呼んで、イベントビルダーで扱うデータを区別する。
37
4. ユーザーからのコマンドを受け付ける（コマンド受付スレッド）
図 4.14にイベントビルダーのマルチスレッドの様子を示す。
図 4.14: イベントビルダーのマルチスレッド。イベントビルダーはデータ受信（Receive Data）、データ構築（Build Event）、データ送信（Send Data）、コマンド受信（Receive Command）の処理をマルチスレッドで並列して行う。
マルチスレッドとは、1つのプロセス内にスレッドと呼ばれる処理単位を複数生成し、並行して処理を行う機能である。イベントビルダーをマルチスレッドにすることによって、コレクター同様次のような利点があげられる。
1. データの受信、データの構築、データの送信を並列処理にすることで、コレクターからのデータ受信待ちのときやネットワークがつまってデータの送信ができないときに他の処理を行うようにすることができる。コレクターからのデータの受信はコレクターによって送信するタイミングが異なるため、順番に処理を行うよりも並列処理にしてデータが送信された順に処理を行えるようにしておくほうが効率が良くなる。
2. スレッドのコントロール機能を実装することによって、データの受信、構築に専念する状態とデータの送信に専念する状態を容易に切り替えることができる。
3. コレクターの数は実験状況によって変化する。コレクターからデータを受信する処理をスレッド化しておけば、コレクターの数だけスレッドを生成するようにすることで容易に対応することができる。
38
データ受信スレッド
データ受信スレッドでは、コレクターに接続してコレクターからフラグメントデータを受信し、データ構築スレッドとの共有バッファにそのデータを書き込む処理を行う。データ受信スレッドと共有バッファはコレクターの数だけ生成される。データ受信スレッドはデータ収集のランの開始のコマンドとともに作成され、ランの停止のコマンドがあるまでフラグメントデータの受信を繰り返す。共有バッファが一杯であれば、データ構築スレッドが処理を行って共有バッファに空きができるまで待機する。
データ構築スレッド
データ構築スレッドでは、コレクターの数だけあるデータ受信スレッドとの共有バッファからフラグメントデータを読み出し、同じイベントナンバーのデータを 1つのイベントデータとして構築する処理を行う。構築したイベントデータはデータ送信スレッドとの共有バッファに書き込まれる。データ構築スレッドはデータ収集のランの開始のコマンドとともに作成され、ランの停止のコマンドがあるまでフラグメントデータをイベントデータに構築する処理を繰り返す。データ受信スレッドとの共有バッファが空な場合は、データ受信スレッドが処理を行って共有バッファが空でなくなるまで待機する。スレッドとの共有バッファに空きがない場合も同様に他方スレッドが処理を行うまで待機する。
データ送信スレッド
データ送信スレッドは、データ構築スレッドとの共有バッファからイベントデータを読み出し、そのデータをレコーダーに送信する処理を行う。データ送信スレッドはデータ収集のランの開始のコマンドとともに作成され、ランの停止のコマンドがあるまでイベントデータの送信を繰り返す。共有バッファが空な場合は、データ再構築スレッドが処理を行って共有バッファが空でなくなるまで待機する。またデータ送信スレッドは § 4.2.3で述べるオンラインモニターへのマルチキャストを行う。
コマンド受付スレッド
コマンド受付スレッドでは、ユーザーからのコマンドを標準入力で受け付けて、そのコマンドの処理を行う。コレクター、レコーダーに接続しているイベントビルダーがユーザーからのコマンドを受け付けることによって、データフローレイヤー全体のプロセスのコマンド制御を行っている。ユーザーからのコマンドには次の 3種類がある。
1. 「START」コマンド。コレクターとレコーダーにデータ収集のランの開始のコマンドを送信する。イベントビルダーはデータ受信、構築、送信のスレッドを作成して、「STOP」のコマンドがあるまで各スレッドは処理を続ける。
2. 「STOP」コマンド。コレクターにデータ収集のランの停止のコマンドを送信する。コレクターがデータ収集のランを停止する最後に送信するヘッダを受信すると、イベントビルダーは各スレッドを終了させる。最後にイベントビルダーヘッダを作成して受信したすべてのコレクターヘッダと一緒にレコーダーへ送信する。ヘッダの形式については § 4.6.2で詳しく述べる。
3. 「EXIT」コマンド。コレクター、レコーダーとの接続を切断し、プロセスを終了する。
コマンド受付スレッドで行われる処理は、本来ユーザーがプロセス管理レイヤーのプロセスマネージャーを通して行われるものである。プロセス管理レイヤーのプロセスがない状態でのデータフローレイヤーのプロセスをコマンド制御するために、イベントビルダーが代替的にプロセス管理を行っている。
39
4.2.2 スローコレクターのデータのイベント構築
§ 4.1.4で述べたように、コレクターからのデータには通常のデータとスローコレクターのデータの 2種類がある。スローコレクターからのデータは、そのデータをイベントビルダーが受信したタイミングで構築されているイベントのデータと一緒に構築される。イベントビルダーは通常のデータを構築し、もしスローコレクターからのデータがバッファにあれば、そのスローコレクターのデータも一緒に構築するという処理を行う。図 4.15にスローコレクターのデータのイベント構築の様子を示す。
図 4.15: スローコレクターのデータのイベント構築の様子。イベントビルダーは、スローコレクターからのデータがあればそのデータを通常のコレクターと一緒にイベントとして構築し、なければ通常のコレクターのデータのみを構築する。
4.2.3 マルチキャスト
オンラインモニターでデータを閲覧するために、イベントビルダーはオンラインモニターが接続しているネットワークへUDPのマルチキャストを用いてイベントデータを送信する。マルチキャストとは、ネットワーク上の複数の特定の相手に対してデータを送信する通信方法である。マルチキャストグループを特定するマルチキャストアドレスというアドレスにデータを送信することで、マルチキャストグループに登録されているすべての相手にデータを送信することができる。オンラインモニターをマルチキャストグループに登録し、イベントビルダーがそのマルチキャストアドレスにデータを送信することでオンラインモニターはイベントビルダーからのデータを受信する。図 4.16にマルチキャストでのデータ通信の様子を示す。イベントビルダーはオンラインモニターへのデータの送信方法にマルチキャストを用いることによって、
40
図 4.16: マルチキャストでのデータ通信。イベントビルダーはマルチキャストグループ宛に一度データを送信するだけで、マルチキャストグループに登録しているオンラインモニターすべてが同じデータを受信することができる。
1. イベントビルダーは個々のオンラインモニターと接続を確立してデータを送信する必要がなく、マルチキャストアドレスへデータを一度送信するだけですべてのオンラインモニターにデータを送信することができる
2. オンラインモニターはイベントビルダーがデータを送信しているマルチキャストグループに登録することによってデータを受信することができるので、イベントビルダーはオンラインモニターの数を気にする必要がない
3. イベントビルダーはオンラインモニターの有無にかかわらずデータをマルチキャストグループ宛に送信し続けているので、オンラインモニターは自由なタイミングで起動してデータを受信することができる
といった利点があげられる。オンラインモニターはデータ収集中のデータの確認が目的であるから、必ずしも収集しているすべて
のデータを受信する必要はない。このため、通信にはデータ損失がありえる UDPを用いても問題はないとした。イベントビルダーの負荷を軽減できるようにマルチキャストでデータを送信する頻度を調整できるようにした。データをマルチキャストする回数は、nイベントに 1回というように nをイベントビルダーが起動時に読み込む設定ファイルで設定できるようになっている。
4.3 レコーダー
レコーダーは、イベントビルダーで構築された 1イベントデータを受信し、ファイルに書き出してハードディスクに保存するプロセスである。コレクターが増加すればイベントビルダーのイベント再構築に時間がかかることが予想できたため、ファイルに書き出す処理はイベントビルダーではなくレコーダーが行う。図 4.17にレコーダーの概観図を示す。
41
図 4.17: レコーダーの概観図。レコーダーはイベントビルダーから受信したデータをファイルに書き出す処理を行う。
4.4 オンラインモニター
データ収集時に正しいデータが収集できているかどうかを確認することは、実験を行う上で重要である。データ収集のランを止めてハードディスクに記録されたデータを解析するのではなく、データ収集中にリアルタイムで収集しているデータを確認できる仕組みをオンラインモニターとして実装した。オンラインモニターは、イベントビルダーがマルチキャストするデータを受信し、そのデータを解析して必要な情報を表示する。図 4.18にオンラインモニターの概観図を示す。
図 4.18: オンラインモニターの概観図。オンラインモニターはイベントビルダーがマルチキャストで送信したデータを受信し、データを解析してユーザーに表示する。
オンラインモニターは複数実装されることを想定している。1つのオンラインモニターで表示したいすべての情報を扱うのではなく、必要な情報毎にオンラインモニターを分化して実装する。これによって実験状況の変化に対して、1つのオンラインモニターを書き換えるのではなく新しいオンラインモニ
42
ターを追加するといった形で対応することができる。
4.4.1 オンラインモニターでの処理
オンラインモニターでの処理の流れは次のようになっている。
1. イベントビルダーからデータを受信する（データ受信処理）
2. 受信したデータを解析して表示する（データ表示処理）
オンラインモニターは起動している間、1と 2 を繰り返す。オンラインモニターはデータ収集のランに関係なく自由に起動と終了を行うことができる。
データ受信処理
データ受信処理では、イベントビルダーがマルチキャストで送信するデータを受信する処理を行う。イベントビルダーがデータを送信しているマルチキャストグループに登録しておくことでデータを受信することができる。
データ表示処理
データ表示処理では、受信したデータを解析してユーザーに表示する処理を行う。データの表示には標準出力や必要に応じてグラフ化ソフトウェアを用いる。高エネルギー物理実験分野では、CERN（欧州原子核研究機構）が開発した PAW [12]やROOT [13]とよばれる解析ソフトウェアが広く使用されている。データ表示処理で行われる処理はユーザーが実装する。
4.4.2 ユーザーが実装する処理
オンラインモニターは表示させたいデータの内容によってユーザーが実装する。オンラインモニターの実装を容易にするため、オンラインモニターの処理はフレームワークとしてユーザーに提供される部分と、ユーザーが実装する部分に分離している。フレームワークの部分では、イベントビルダーがマルチキャストしているデータを受信する処理を行う。ユーザーが実装する部分では、受信したデータを解析して表示する処理を行う。ユーザーが実装する部分は次の 3つの処理で構成される。
userInit 初期化処理。は、オンラインモニターを起動したときに行う処理で、データの解析に必要なパラメーターファイルの読み込み等の処理を行う。
userMon データ表示処理。データを受信するごとに行われる処理で、ユーザーは受信したデータを解析して閲覧したい情報を表示させる処理を行う。
userFinal 終了処理。オンラインモニターを終了するときに行う処理で、データの表示に使用していたソフトウェアを終了させる等の処理を行う。
図 4.19にオンラインモニターの処理の流れの中にユーザーの処理がどのタイミングで行われているかを示した。
43
図 4.19: オンラインモニターの処理の流れ。処理の流れの中にユーザーの処理が行われるタイミングを示してある。
44
4.5 コマンド制御
本来データ収集のランの開始や停止といったコマンドの管理ははプロセス管理レイヤーで行われる。プロセス管理レイヤーのプロセスがない状態でもデータフローレイヤーのプロセスのコマンド制御ができるようにするため、代替的な機能としてイベントビルダーにコマンド制御機能を実装させた。イベントビルダーからコレクターとレコーダーへのコマンドは、データの送受信と同じソケットを用いて行われる。
4.5.1 データ収集開始時のコマンドの流れ
データ収集のランを開始するときは、次のようなコマンドの流れで行われる。
1. ユーザーがイベントビルダーに「START」コマンドを入力する。
2. 「START」コマンドを入力されたイベントビルダーは各コレクターとレコーダーに「WAKE UP」コマンドを送信する。
3. 「WAKE UP」を受信したコレクターはヘッダを作成してイベントビルダーへ送信する。「WAKEUP」を受信したレコーダーはファイルをオープンし、ヘッダを作成してイベントビルダーへ送信する。
4. すべてのプロセスからヘッダを受信したイベントビルダーは各コレクターに「START」コマンドを送信し、レコーダーに「START」コマンドとしてランヘッダを作成して送信する。
5. 「START」コマンドを受信したコレクターはデータ収集を開始し、全体としてもデータ収集が開始する。
ヘッダの形式については § 4.6.2で述べる。
4.5.2 データ収集停止時のコマンドの流れ
データ収集のランを停止するときは、次のようなコマンドの流れで行われる。
1. ユーザーがイベントビルダーに「STOP」コマンドを入力する。
2. 「STOP」コマンドを入力されたイベントビルダーは各コレクターに「STOP」コマンドを送信する。
3. 「STOP」コマンドを受信したコレクターはデータ収集スレッドを停止し、バッファに残っているデータをすべて送信した後、ヘッダを作成してイベントビルダーに送信する。（コレクターの停止）
4. イベントビルダーはコレクターからヘッダが送信されてくるまでイベント構築を続け、コレクターからヘッダを受信すると自らのヘッダを作成してコレクターのヘッダと一緒にランヘッダとしてレコーダーへ送信する。（イベントビルダーの停止）
5. レコーダーはランヘッダを受信すると、ランヘッダをファイルに書き込んでファイルをクローズする。（レコーダーの停止）
ヘッダの形式については § 4.6.2で述べる。
45
4.6 データフォーマット
4.6.1 パケット
ネットワークに分散しているプロセス間では、データの通信をネットワークを介して行う。ネットワークでのデータの送受信をデータの中身に関係なくどんなデータでも同じように行うため、すべてのデータはネットワークを流れるときにパケットと呼ぶ形式を取るようにした。図 4.20にパケットの形式を示す。
図 4.20: パケットの形式。ネットワークを流れるデータはすべてこの形式に従う。
Packet Start 1バイト（8ビット）で、その値は常に 0xd4（1101 0100）である。ここで 0xは続く数字が 16進数であることを示す接頭語であり、（）内はビットの状態を 2進数であらわしたものである。Packet Startによってデータの始まりを確認する。また Packet Endとともに受信したデータが正しくパケットの形式であることを確認する。
Packet ID は 1バイト（8ビット）で、主に上位 4ビットでデータの種類を判断し、下位 4ビットでプロセスの種類を判断する。表 4.1にデータフローを管理するプロセスで使用しているPacket IDの一覧表を示す。
Packet Size 4バイトで、符号無し整数型（unsigned int型）の値である。Packet Sizeは、Data Bodyのデータの長さをバイト数単位であらわす。Data Bodyの大きさによって受信するパケットの大きさが変わるため、Packet Sizeを読んでパケットの大きさを判断することで、データをパケットとして正しく受信することができる。
Packet End 1バイト（8ビット）で、その値は常に 0xd2（1101 0010）である。Packet Endによってデータの終わりを確認する。ネットワークを流れるデータは必ずしも本 DAQシステムのものだけではないので、Packet Startと Packet Endを確認することで、受信したデータが間違いなく本DAQシステムで扱っているデータであることを保証する。
Data Body データ本体をあらわし、この部分がコレクターデータやイベントビルダーヘッダ等のデータが書き込まれる部分である。
46
表 4.1: Packet IDの一覧表。上位 4ビットでヘッダ、データ、コマンドを区別し、下位 4ビットでコレクター、イベントビルダー、レコーダーを区別する。アクセプトとはコレクター、レコーダーがイベントビルダーに接続したときの合図として送信するデータのことをあらわす。
Packet ID 内容0001 0001 通常コレクターからのアクセプト0001 0010 スローコレクターからのアクセプト0001 0011 レコーダーからのアクセプト0010 0001 コレクターのヘッダ0010 0010 イベントビルダーのヘッダ0010 0011 レコーダーのヘッダ0010 0100 ファイルのヘッダ0011 0001 イベントビルダーからのコマンド0011 0010 イベントビルダーへのリプライ0100 0001 コレクターからのデータ0100 0010 イベントビルダーからのデータ
4.6.2 ヘッダ
ファイルとして保存されるデータには、イベントのデータだけではなく、必要な情報がヘッダとして書き込まれる。コレクター、イベントビルダー、レコーダーの各プロセスはデータ収集ランごとにヘッダを作成する。
ベースヘッダ
コレクター、イベントビルダー、レコーダーのヘッダは内容に共通した部分が多いので、ベースヘッダというヘッダの形式を作成した。図 4.21のにベースヘッダの形式を示す。
図 4.21: ベースヘッダの形式。最初の 20バイトはコレクター、イベントビルダー、レコーダーで共通であり、Header Dataの部分がそれぞれで異なる。
Version 4バイトで、4つの符号無し文字型（unsigned char型）で構成される。バージョンは、1.0.1.βのようにあらわす。
47
Start Time / Stop Time ともに 8バイトで、timeval構造体型の値である。timeval構造体はC言語で<sys/time.h>で次のように定義されている。
struct timeval {
time_t tv_sec; /* 秒 */
suseconds_t tv_usec; /* マイクロ秒 */
}
数値は UNIX紀元（1970年 1月 1日 00:00:00 UTC）からの経過時間で、そのプロセスがデータ収集のランを開始した時間と停止した時間をあらわす。
Header Data バージョンと時間情報以外に各プロセスごとに必要なデータが書き込まれる部分である。
コレクターヘッダ
コレクターヘッダのHeader Dataの部分を図 4.22に示す。
図 4.22: コレクターヘッダのHeader Dataの部分。コレクターヘッダ全体はベースヘッダの形式をしており、ここではHeader Dataの部分だけを図に示している。# of‥は‥の数をあらわす。
Collector Name 32バイトで、文字列である。Collector Nameはそのコレクターの名前をあらわす。ユーザーは作成したコレクターに 32バイトまでの名前を自由につけることができる。
# of Collected Data 4バイトで、unsigned int型の値である。# of Collected Dataは、そのコレクターが収集したデータの数をあらわす。各コレクターが収集するデータの数は、データ収集のランの停止のタイミングは各コレクター同士で必ずしも一致しないので、各コレクターごとに記録しておく。
イベントビルダーヘッダ
イベントビルダーヘッダのHeader Dataの部分を図 4.23 に示す。
# of Fast Collectors / # of Slow Collectors ともに 1バイトで、unsigned char型の値である。#of Fast Collectorsと# of Slow Collectorsは、それぞれそのデータ収集のランのDAQシステム内の通常のコレクターの数とスローコレクターの数をあらわす。コレクターの数は多く見積もっても8ビットであらわせられる最大値の 255を越えることはないと判断し、1バイトとした。
48
図 4.23: イベントビルダーのHeader Dataの部分。イベントビルダーヘッダ全体はベースヘッダの形式をしており、ここではHeader Dataの部分だけを図に示している。# of‥は‥の数をあらわす。ここにある Fast Collectorとは通常のコレクターのことである。
# of Built Events 4バイトで、unsigned int型の値である。# of Built Eventsは、コレクターから受信したデータをイベントとして構築した数をあらわす。データ収集ランが停止したときまでに各コレクターが収集したデータの数は異なり、イベントビルダーは全てのコレクターがイベントビルダーに送信できた分までをイベントとして構築する。
# of Failed Events 4バイトで、unsigned int型の値である。# of Failed Eventsは、イベント構築に失敗した数をあらわす。イベントビルダーの開発当初は、各コレクターのデータに含まれている Event Sync IDと呼ばれる同一のイベントであることを示す値のチェックをイベントビルダーが行っていたため、Event Sync IDが一致せずにイベント構築できなかったイベントの数を数えて記録していた。現在ではイベントビルダーにかかる負荷を減らすために、このチェックをオンラインモニターで行うようにしているため、この数値は必ず 0となる。
レコーダーヘッダ
レコーダーヘッダのHeader Dataの部分を図 4.24に示す。
図 4.24: レコーダーヘッダのHeader Dataの部分。レコーダーヘッダ全体はベースバッファの形式をしており、ここではHeader Dataの部分だけを図に示している。# of‥は‥の数をあらわす。
49
Run No. 4バイトで、unsigned int型の値である。Run No.はデータ収集ランの番号をあらわす。
# of Received Events 4バイトで、unsigned int型の値である。# of Received Eventsは、レコーダーがイベントビルダーから受信してファイルに記録したイベントの数をあらわす。イベントビルダーはデータ収集ランを停止するときに、それまでに構築したイベントデータはすべてレコーダーに送信するため、# of Received Eventsはイベントビルダーヘッダの# of Built Eventsと一致するはずである。
Flag 2バイトで、各ビットの状態でファイルのレコードモードをあらわす。現在使用しているのは上位1ビットのみで、ファイルが正しく閉じられたかどうかを判断している。レコーダーは、イベントビルダーとの接続が予期せず切断された等でデータ収集ランが正しく停止しなかったときに Flagの上位 1ビットを 1とし、正常に停止してファイルを正しく閉じたときは 0とする。残りの 15ビットは将来の拡張性のために確保されている。
ランヘッダ
ランヘッダは、ファイルの先頭に書き込まれるヘッダである。ランヘッダは各プロセスのヘッダとは違ってベースヘッダの形式ではなく、各プロセスのヘッダとコメント、解析用フラグから構成される。図 4.25にランヘッダの形式を示す。
図 4.25: ランヘッダの形式。コレクターヘッダの数はそのデータ収集ランのときにあったコレクターの数だけランヘッダに含まれる。
Flag for Analysis 2バイトで、データ解析用に後から書き込むための空間である。ファイル作成時には何も書き込まれない。Flag for Analysisで判断する情報としては、そのデータがジャンクデータであるかどうかを判断するフラグ等を考えている。ジャンクデータとは、実験セットアップや回路の間違い等で物理として必要なデータが書き込まれていないデータのことをいう。
Comments 20キロバイトで、文字列である。Commentsは、そのデータ収集ランの実験セットアップ等をユーザーが自由に書くことのできる空間である。Commentsに書き込む機能をどう実装するかは検討中であり、現在は何も書き込まれていない。
50
Flag for AnalysisとCommentsに続いて、Recorder Header、EventBuilder Header、Collector Headerがこの順番で構成される。Collector Headerは通常のコレクターからスローコレクターの順に、そのデータ収集ラン時のコレクターの数だけ含まれる。
4.6.3 データ
コレクターが収集したデータ（コレクターデータ）は、イベントビルダーに送信される。イベントビルダーはコレクターから受信したコレクターデータをイベント（イベントデータ）として構築する。
コレクターデータ
コレクターデータは、モジュールから読み込んだ ADC、TDCデータ等が書き込まれるデータ本体（Data）と、データを管理するために必要な情報を書き込む部分（Data Header）から構成される。コレクターはDataの先頭にData Headerを付け足して、さらに § 4.6.1にあるパケットとしてイベントビルダーに送信する。コレクターデータのData Bodyの部分を図 4.26に示す。
図 4.26: コレクターデータのData Bodyの部分。コレクターデータ全体はパケットの形式をしており、ここではData Body の部分だけを図に示している。
Collector No. Collector No.は 1バイトで、unsigned char型の値である。Collector No.は、コレクター番号をあらわす。ユーザーはコレクターに任意のコレクター番号をつけることができる。CollectorNo.によってこのコレクターデータがどのコレクターのデータであるかを識別する。
Run No. Run No.は 4バイトで、unsigned int型の値である。Run No.は、データ収集ランの番号をあらわす。イベントデータではなくコレクターデータをモニターしようとしたときに、コレクターデータの中にラン番号が書き込まれているほうが都合がよいため、コレクターデータとしてラン番号が書き込まれている。
Event No. Event No.は 4バイトで、unsigned int型の値である。Event No.は、データ収集ランごとに収集したデータに 1から順につけられるイベントナンバーをあらわす。イベントナンバーが一致するようにイベントビルダーはコレクターデータをイベントデータに構築する。
51
Data Dataは、ADCデータや TDCデータ等のハードウェアから収集したデータが書き込まれる部分である。§ 4.1.3で述べた共有バッファに 1イベント分のデータとして書き込まれたデータが、このDataの部分のデータになる。
Reserved Reservedは 1バイトで、現在は何も使用されていない空き領域である。Reservedによって読み出すデータの切れ目を 2の倍数に調整している。パソコンは 4バイト、2バイトごとにメモリを参照するので、データの切れ目が奇数になるとデータの読み書きに時間がかかってしまう。RunNo.、Event No.を Collector No.に詰めてしまうと、Collector No.より後ろにあるデータの先頭は全て奇数番目のメモリに位置してしまい、これを避けるためにReservedとして 1バイト分を確保している。
イベントデータ
イベントデータは、各コレクターから送信される複数のコレクターデータ（Collector Data）と、コレクターデータ同様データを管理するために必要な情報を書き込む部分（Data Header）から構成される。イベントビルダーはCollector Dataをパケットのまま並べた先頭にData Headerを付け足して、さらに§ 4.6.1にあるパケットとしてレコーダーに送信する。イベントデータの Data Bodyの部分を図 4.27に示す。
図 4.27: イベントデータのData Bodyの部分。イベントデータ全体はパケットの形式をしており、ここではData Bodyの部分だけを図に示している。
Run No. 4バイトで、unsigned int型の値である。Run No.はデータ収集ランの番号をあらわす。ランヘッダにラン番号は書き込まれているが、オンラインモニターが受信したイベントデータから現在のデータ収集ランのラン番号を知ることができるように、イベントデータの中にもラン番号が書き込まれている。
# of Fast Collector Data / # of Slow Collector Data ともに 1バイトで、unsigned char型の値である。# of Fast Collector Dataと# of Slow Collector Dataは、それぞれこのイベントデータに含まれる通常のコレクターデータの数とスローコレクターデータの数をあらわす。イベントビルダーでは、スローコレクターからはデータがあったときだけそのスローコレクターデータを通常のコレクターデータと一緒にイベントとして構築する。スローコレクターデータがなければ
52
通常のコレクターデータだけをイベントとして構築する。# of Slow Collector Dataは接続しているスローコレクターの数以下の値となる。従って、イベントヘッダに含まる# of Fast Collectorsと# of Slow Collectorsの値と# of Fast Collector Dataと# of Slow Collector Dataの値は必ずしも一致しない。
Collector Data コレクターの数だけ含まれる。コレクターから受信したコレクターデータはパケットの形式をしており、そこからData Bodyを取り出すのではなく、パケットのまま Collector Dataとしてイベントデータの中に書き込む。これは、データ解析時にコレクターデータをパケットとして取り出せるようにするためである。
Event No.はコレクターデータの中に書かれているため、イベントデータとしては書かれていない。
4.6.4 ファイル
レコーダーは、ファイルの先頭にランヘッダを記録し、その後ろにイベントビルダーから送信されるイベントデータを記録する。ファイルの形式を図 4.28に示す。
図 4.28: ファイルの形式。先頭にランヘッダがあり、収集したイベント分のイベントデータがその後に記録される。
Run Headerは、全てのプロセスのヘッダで構成されるランヘッダである。Event Dataは、イベントビルダーから受信したイベントデータである。Run Headerと Event Dataはどちらも、パケットからData Bodyを取り出すのではなく、パケットのままのものとなっている。これは、ファイルから読み出すオフラインの解析とオンラインモニターでの解析を同じ処理で行うことができるようにするためである。パケットのままファイルに保存しておけば、オンラインでデータをネットワークからパケットとして受信して解析するのと同じように、オフラインでデータをファイルからパケットとして読み出して解析することができる。
53
第5章 FORESTのデータ収集での性能評価
実装したデータフローレイヤーのプロセスを用いて、FORESTのデータを収集した。実験は GeVγ
ビームラインで 2007年の 11月と 12月に 2度行った。11月の実験では、データ収集効率としてライブタイムを測定し、シミュレーションと比較することでDAQシステムの性能を評価した。12月の実験では、実装したオンラインモニターでリアルタイムにデータを確認しながらデータの収集を行った。
5.1 実験セットアップ
本実験時までに、FORESTは SCISSORS IIIとBackward Gammaの建設が完了していた。FORESTのデータとして、SCISSORS IIIと Backward Gammaのデータを収集した。データ収集は TKO-SMPコレクター、VME-TDCコレクター、FERA-UIO コレクターと呼ばれる 3つのコレクターを作成して行った。図 5.1に検出器のデータと収集するコレクターの対応を示す。
図 5.1: 検出器のデータとコレクターの対応。TKO-SMPコレクターは STB-Tagger IIのTDCと SCIS-SORS IIIの ADC、TDC のデータ、VME-TDCコレクターは Backward Gammaの TDCのデータ、FERA-UIOコレクターは Backward GammaのADCのデータを収集する。
5.1.1 TKO-SMPコレクター
TKO-SMPコレクターでは、SCISSORS IIIを構成するCsIクリスタル 192本のADCデータとTDCデータ、STB-Tagger116本のTDCデータを収集する。TKO-SMPコレクターには 2台のTKOクレート
54
とTKO規格のADC、TDCモジュールを用いた。ADC、TDCデータは、それぞれのTKOクレートでSuper Control Header（SCH）に集められ、VMEbus規格のモジュールである Super Memory Partner（SMP）へ蓄積される。蓄積されたデータはVMEbusを介してパソコンで収集される。トリガーの検知には、VMEbus規格の林栄精器社の Interrupt & I/Oレジスタ RPV-130を用いて信号があるかどうかをポーリングで確認し、データを収集するようにした。図 5.2に SMP-TKOコレクターのモジュールの接続図を示す。
図 5.2: SMP-TKOコレクター。2台のTKOクレートで収集されたADC、TDCデータは SCHモジュールから SMPモジュールを経由してパソコンまで転送される。
SCHモジュールはスパースデータスキャンと呼ばれる方式で各ADC、TDCモジュールからデータを読み出す。スパースデータスキャンは、すべてのデータを読み出すのではなく、指定された条件に従って有効なデータのみを読み出す方式である。スパースデータスキャンによって不必要なデータを読み出さないようにしてデータの読み出しにかかる時間を短縮している。スパースデータスキャンのモードはSMPモジュールで指定される。TKO-SMPコレクターではコンペアスパーススキャンというモードで比較する値を 0とすることで、シグナルのなかったTDCチャンネルのデータを収集しないようにした。
SMPモジュールは TKO側と VMEbus側に 2つのバッファを持っていおり、TKO側メモリに TKOからのデータを書き込んでいるときにもVMEbus側メモリのほうへVMEbusからアクセスすることができる。またこの 2つのバッファは設定した条件で交換を行うことができる。一方のメモリへの TKOからのデータの書き込みが終了した時点でバッファを交換することで、直前までに収集されたデータをVMEbusより読み出し、それと同時にもう一方のバッファを用いてTKOからのデータ収集を行うことが可能である。これにより、パソコンが SMPモジュールからデータを読み出している間にも次のトリガーを受け付けてデータ収集を行うことができる。バッファの交換は Interrupt & I/Oレジスタにトリガー信号が入力された時点で行った。図 5.3に SMPモジュールのバッファの様子を示す。
55
図 5.3: SMPモジュールのダブルバッファの様子。2つのバッファがあることでTKOからの書き込みとパソコンへの読み出しを同時に行うことができる。
5.1.2 VME-TDCコレクター
VME-TDCコレクターでは、Backward Gammaを構成する Lead/SciFi 252本のTDCデータを収集する。VME-TDCコレクターにはVMEbus規格のTDCモジュールを用いた。TDCモジュールで収集されたTDCデータはVMEbusを介してパソコンまで転送される。トリガーの検知には、VMEbus規格の林栄精器社の Interrupt & I/Oレジスタ RPV-130を用いて信号があるかどうかをポーリングで確認し、データを収集するようにした。図 5.4にVME-TDCコレクターのモジュールの接続図を示す。
図 5.4: VME-TDCコレクター。TDCデータはVMEbusを介してパソコンに転送される。
使用したTDCモジュールであるCAEN社の 128チャンネルTDCのV1190Aは、内部にバッファを持ち、複数イベント分のデータを蓄積しておくことができる。ライブタイムの測定を行った 11月の実験では、データの読み出し回数を減らすことで処理時間を短くすることができるため、20イベントに 1回データを読み出すようにした。バッファは FIFO（Fast In Fast Out）バッファと呼ばれるもので、バッファに入ってきた順にバッファからデータを取り出すので書き込みと読み出しを同時に行うことができる。12月の実験では、1イベントごとに読み出したほうが処理がはやいことがわかったため、1イベントごとに処理を行うように変更した。
56
5.1.3 FERA-UIOコレクター
FERA-UIOコレクターでは、Backward Gammaを構成する Lead/SciFi 252本のADCデータを収集する。FERA-UIOコレクターにはCAMACモジュールであるFERAとVMEモジュールであるUIOを用いた。サンリツオートメイション社のVME CPU SVA041を用いてUIOモジュールを通して FERAモジュールのデータを読み出し、イベントビルダーにデータを送信する。FERAモジュールのコントロールには FERAドライバーを用いた。トリガーの検知には、VMEbus規格の林栄精器の I & I/OレジスタRPV-130 を用いて信号があるかどうかをポーリングで確認し、データを収集するようにした。図 5.5に FERA-UIOコレクターのモジュールの接続図を示す。
図 5.5: FERA-UIOコレクター。VME CPUを用いてUIOモジュールが読み出した FERAのデータを収集する。
LeCroy社の FERA（Fast Encording Readout ADC）MODEL 4300B は高速読み出しが可能なCA-MAC規格のADCモジュールで、前面のパネルにFERAバスと呼ばれるバスがある。FERAバスを用いてVMEbus規格のモジュールであるUIOからアクセスすることで、CAMACからアクセスするよりも高速にデータを読み出すことができる。FERAのコントロールは LeCroy社の FERAドライバーMODEL4301を用いて行った。FERAモジュールはペデスタルサブトラクションという機能があり、読み込んだ値（ペデスタル値）より値の小さいデータは収集しないように設定することができる。これにより応答しなかった検出器のデータを収集しなくてすむため、読み出すデータ量を減らすことでデータの読み出しにかかる時間を短縮することができる。実験では最初にペデスタルデータを収集し、そのデータを用いてペデスタルサブトラクションを行ってデータを収集した。
UIO（Universal I/O）モジュールはもともと論理回路をユーザーが自由に作成できるプログラマブルロジックデバイスモジュールであり、FERAドライバーをコントロールして FERAバスからデータを収集できるようにしてある。UIOモジュールは SMPモジュールと同様にバッファを 2つ持ち、バッファを交換することでデータの読み出しと書き込みを同時に行うことができる。バッファは複数イベント分のデータを蓄積しておくことができ、実験では 20イベントに 1回バッファの交換を行ってデータを読み出すようにした。
5.1.4 スローコレクター
FOREST実験での導入を考えているスローコレクターの開発はまだ行われていないため、今回の実験ではテスト用のスローコレクターを実装した。テスト用のスローコレクターは、1秒おきに 50バイト程度のデータをイベントビルダーに送信する。これを用いてスローコレクターが導入されたときの DAQシステムのデータ収集効率に変化があるかどうか確かめた。
57
5.1.5 トリガーシステム
ADC、TDCなどのハードウェアモジュールは、検出器からの生信号をデジタル信号に変換するため、モジュールの種類によって数十 nsecから数百 µsec程度の処理時間を要する。またコレクターのバッファが一杯になれば、データ送信が行われてバッファに空きができるまでデータを収集することができなくなる。このように、コレクターはトリガーが発生してからそのデータ処理を行って次のトリガーを受け付けられるようになるまでに時間がかかる。この時間をコレクターの不感時間と呼ぶ。各コレクターは不感時間の間はトリガーが発生しないようにする必要があるため、不感時間に対応す
る BUSY信号を作成し、この信号をトリガーに対する Veto信号にしている。コレクターの BUSY信号は、
1. トリガーが発生すると同時にラッチモードの信号を発生させて、
2. データの読み出しが終了したらその信号を解除する
ことで作成した。図 5.6に BUSY信号の概念図を示す。
図 5.6: BUSY信号の概念図。生成したBUSY信号をトリガー信号のVetoにいれることでデータ処理中にトリガーが発生しないようにしている。
コレクターが複数ある場合、すべてのコレクターのデータ処理が終了するまでトリガーを発生させることはできないので、トリガーに対するVeto信号はすべてのコレクターの BUSY信号のORをとった信号となっている。図 5.7にコレクターが 3つあったときのトリガーに対するVetoのかけかたを示す。
5.2 ライブタイムの測定
§ 5.1.5で述べたように、各コレクターはデータ収集の処理を行っている最中は、トリガーが発生したとしてもそのトリガーに対するデータ収集を行うことができない。ここでトリガーが発生した数をNReq、データ収集を行うことのできたトリガーの数をNAcc とすると、
η =NAcc
NReq(5.1)
で定義するライブタイム ηを用いて、DAQシステムのデータ収集効率を評価することができる。
58
図 5.7: 複数のコレクターがあるときのVetoのかけかた。検出器の信号から作成されたトリガーをRequestTrigger、Veto信号がかかっていないときに発生したRequest TriggerをAccept Triggerと呼ぶ。AcceptTriggerが実際にデータ収集行うトリガーである。BUSY信号はすべてのコレクターのORを取るため、BUSY信号の長さはデータの処理にもっとも時間のかかったコレクターで決まる。
ある一定時間に発生したトリガー数と実際にデータ収集を行ったトリガー数をスケーラーで計数し、DAQシステムのデータ収集効率としてライブタイムを求めた。ライブタイムはコレクターの不感時間に発生してデータ収集ができなかったトリガーの数で決まるので、トリガーレートに依存する。トリガーレートは加速器のビーム強度を変えることで調整した。標的に入射するガンマ線は、加速器で周回している電子にラジエーターを挿入し、その周回電子が制動放射を起こすことで発生する。ラジエーターの挿入速度が一定ならば、加速器で周回している電子の数が増加すれば単位時間当たりに発生するガンマ線の量が増加する。単位時間当たりに発生するガンマ線の量が増加すればイベントが起こる確率が増加するので、トリガーレートが増加する。標的には炭素 10mmを使用し、加速器のビーム強度を 1 mA、2mA、3mA、4mAとすることで、ト
リガーレートが 500Hzから 2.5 kHz の間となる 4点についてライブタイムの計測を行った。また、DAQシステムの性能の律速となっている部分を調査するために、
1. 各コレクターをデモコレクターとして動かした場合
2. 各コレクター 1つをイベントビルダーに接続した場合
3. 3つのうち 2つのコレクターをイベントビルダーに接続した場合
4. スローコレクターを接続した場合
のようにDAQシステムの設定を変更して、それぞれについてライブタイムの測定を行った。
5.2.1 測定結果
3つすべてのコレクターをイベントビルダーに接続したときの全体のライブタイムと各コレクター 1つだけをイベントビルダーに接続したときのライブタイムを比較したグラフを図 5.8に示す。全体のライブタイム（ALL）はトリガーレート約 1.5 kHzに対して 70%弱程度であった。これは目標値であるトリガーレート 2 kHzで 80%のライブタイムには及ばなかった。
59
図 5.8: 全体のコレクターと各コレクターのライブタイム。w/ EBはイベントビルダーに接続していたことをあらわす。
全体のライブタイムは TKO-SMPコレクターのそれとほぼ同じであり、TKO-SMP コレクターの性能がほとんとDAQシステム全体の性能を決定していることがわかった。ただ、全体のライブタイムがTKO-SMPコレクターより低くなっていることから、TKO-SMPコレクター以外にもDAQシステム全体の性能の律速となっている部分があると考えられる。§ 5.2.2でシミュレーションを行い、ライブタイムの律速となっている部分を調べた。
各コレクターをデモで動かしたときの比較
それぞれのコレクターについて、コレクターをイベントビルダーに接続して動作させたときのライブタイムと、イベントビルダーに接続せずにデモコレクターとして動作させたときのライブタイムの比較を行った。デモコレクターはイベントビルダーにデータを送信するかわりに、データをファイルに書き出す。デモコレクターではファイルに書き出す処理に時間がかかっている可能性も考えられるので、ファイルに書き出す処理を行わないようなモードも作成して一緒にライブタイムを測定した。各コレクターについて、
1. イベントビルダーに接続してデータを送信する（w/ EB）
2. イベントビルダーに接続せずデータをファイルに書き出す（demo）
3. ハードウェアから読み出したデータに対して何も処理を行わない（write off）
としたときのライブタイムの測定を行った。図 5.9に各コレクターごとにイベントビルダーに接続したときとデモで動作したときを比較したライブタイムを示す。
demoでは、デモコレクターモードで動作しイベントビルダーに接続せず、データをローカルにファイルに書き出す。write offでは、デモコレクターモードで動作しイベントビルダーに接続せず、ファイルの書き出しも行わずハードウェアからのデータの読み出しのみを行う。w/ EBでは、通常のコレクターとして動作しイベントビルダーに接続して、データをイベントビルダーに送信する。すべてのコレクターにおいて、モードの違いによるライブタイムの変化は見られなかった。もし demo
とw /EBでライブタイムに差が見られれば、コレクターのネットワークへの送信もしくはイベントビルダーやレコーダーでの処理がデータ収集効率に影響を与えていると考えることができる。従ってこの比
60
図 5.9: 各コレクターごとに比較したライブタイム。上から順にTKO-SMPコレクター、VME-TDCコレクター、FERA-UIOコレクターでそれぞれイベントビルダーに接続したときとデモで動作したときを比較したライブタイムをあらわす。
61
較からは、すべてのコレクターにおいてコレクター単体でのデータ収集効率は、イベントビルダーではなくハードウェアからのデータの読み出しにかかる時間で決定していると結論付けることができる。
スローコレクターの有無の比較
イベントビルダーでのスローデータの構築が正しく行われているかを確認するため、スローコレクターの有無でのライブタイムの比較を行った。スローコレクターには 1秒ごとに 50バイト程度のデータを送信するテスト用のコレクターを用いた。図 5.10にスローコレクターの有無で比較したライブタイムを示す。
図 5.10: スローコレクターの有無で比較したライブタイム。
スローコレクターの有無によるライブタイムの変化は見られなかった。イベントビルダーが問題なくスローデータを再構築できていることを確認した。核理研の FOREST実験においては、スピル構造を持った加速器のビームを用いるため、スローデー
タの収集は通常のデータ収集を行わないスピルオフ中にトリガーが発生するようにする。従ってスローコレクターの導入自体ではDAQシステムに負荷はかからないと考えている。
5.2.2 シミュレーション
§ 5.1.5で述べたように、コレクターはハードウェアからデータを読み出している間はBUSY信号を発生させ、発生したトリガーに対してのデータ収集を行うことができない。コレクターがトリガーを受け付けられない時間を、コレクターの不感時間と呼ぶ。不感時間は、コレクターが使用するハードウェアモジュールの種類や数によって異なる。この不感時間からシミュレーションを行ってライブタイムを見積もることができる。
各コレクターの不感時間
不感時間は、オシロスコープを用いて実際にBUSY信号の幅を測ることで測定した。トリガーには宇宙線を使用し、デモコレクターでデータを収集した。各コレクターの不感時間を表 5.1に示す。
TKO-SMPコレクターの不感時間は毎イベントにつき約 280 µsecから約 320 µsecであった。VME-TDCコレクターでは、TDCモジュールのバッファに 20イベント分のデータを蓄積するようにしている。
62
表 5.1: 各コレクターのイベントごとの不感時間。VME-TDCコレクターと FERA-UIOコレクターにある ()内の値は、20イベントに 1回あるデータを転送するときの不感時間。
コレクター 不感時間TKO-SMP 300 µsecVME-TDC 170 nsec (1msec)FERA-UIO 60 µsec (70 µsec)
イベントごとの不感時間は TDCデータの変換のみを行うので約 170nsecととても短くなっている。20回に 1回のデータの読み出しを行うはとき約 1 msec程度と TKO-SMPコレクターの不感時間よりも長くなっている。FERA-UIOコレクターもVME-TDCコレクターと同様に、UIOモジュールのバッファに 20イベント分のデータを蓄積するようにしている。UIOモジュールはバッファを 2つ持っていて、そのバッファを交換することで FERAモジュールからのUIOモジュールへのデータの読み出しとUIOモジュールからVME CPUへのデータの読み出しを同時に行うことができる。イベントごとの不感時間は、FERAモジュールがADCデータの変換を行ってUIOモジュールへの転送にかかる時間で、約 60µsecであった。20回に 1回の不感時間は、それにバッファチェンジの時間が追加されて 70µsecとなっている。
シミュレーション方法
表 5.1にある各コレクターの不感時間を用いて、ランダムにトリガーを発生させたときにどれだけトリガーが受け付けられるかをモンテカルロシミュレーションで評価した。次のようなプログラムを作成してシミュレーションを行った。単位時間経過ごとに 1増加する整数値 iClockで時刻を表し、ある時刻 nClocksまでの間にトリガーを
発生させる。その時刻が不感時間であるかどうかを iStateであらわし、不感時間であるときを 1、不感時間でないときを 0とする。時刻を表す iClockを 1増加させるごとに確率 pでトリガーが発生したかどうかを決定する。ここでトリガーの発生数を nRequests、不感時間外に発生したトリガーの数を nAccepts
とする。トリガーが発生した場合、nReqestsを 1増加させる。このとき iStateが 0なら nAcceptsを1増加させ、不感時間の開始時刻をあらわす iStartに現在の iClockの値を記録する。また iStateが1なら iClock - iStartが不感時間 dtより大きいときだけ nAcceptsを 1増加させ、iStartに現在のiClockの値を記録する。これを時刻 nClocksまで行う。nClocks、nRequests、nAcceptの値からトリガーレートとライブタイムが求まる。トリガーレートはトリガーの発生確率 pで調整できる。具体的なプログラムコードは、
iState = 0;
nRequests = 0;
nAccepts = 0;
for ( iClock = 0; iClock < nClocks; iClock++ ) {
urand = ((double)rand()) / RAND_MAX;
if ( urand < p ) {
nRequests++;
if ( iState == 0 ) {
nAccepts++;
iState = 1;
63
iStart = iClock;
}
if ( iState == 1 && iClock - iStart > dt ) {
nAccepts++;
iStart = iClock;
}
}
}
のようにした。各コレクターごとの不感時間を dtに代入してシミュレーションを行った。VME-TDC、FERA-UIOコレクターについては不感時間が 20イベントに 1回値が変わるので、nAcceptsが 20増加するごとに 1回 dtが変わるように、毎イベントの不感時間を dt1、20イベントに 1回の不感時間を dt2
として、
if ( nAccepts % 20 == 0 ) {
dt = dt2;
}
else {
dt = dt1;
}
という処理を forループの最後に追加した。図 5.11に各コレクターの実験データとシミュレーションを比較したグラフを示す。すべてのコレクターのライブタイムは、不感時間から見積もられるシミュレーションの値と一致した。
図 5.8からも読み取れる通り、コレクターを 1つだけを動かした場合のDAQシステムの速度は、イベントビルダーに関係なくハードウェアからのデータの読み出しにかかる時間で決定している。
2つのコレクターを動かしたときのライブタイム
イベントビルダーに接続してデータを収集するコレクターを 2つに限定し、ライブタイムの測定を行った。また、コレクターの不感時間を用いてシミュレーションの値との比較も行った。図 5.12に 2つのコレクターをイベントビルダーに接続したときのライブタイムのグラフを示す。それぞれのコレクター 1つだけのときのデータも同時にプロットし、それぞれのシミュレーション結果と比較している。2つのコレクターを接続したときの不感時間は、それぞれのコレクターの不感時間の長いほうのものであるとした。
TKO-SMPコレクターとVME-TDCコレクターの場合、不感時間は毎イベントはTKO-SMPコレクターの 300 µsecで、20イベントに 1回はVME-TDCコレクターの 1msecになると考えられる。この値を用いてシミューレーションで求めたライブタイムの値は、確かにTKO-SMPコレクターとVME-TDCコレクターの 2つをイベントビルダーに接続したときのライブタイムの値と一致した。
TKO-SMPコレクターと FERA-UIOコレクターの場合は、不感時間は常に FERA-UIOコレクターのほうがTKO-SMPコレクターのよりも短いため、TKO-SMPコレクターの性能でこの 2つをイベントビルダーに接続した DAQシステムの性能は決定すると考えられる。確かにこのときの DAQシステムのライブタイムは TKO-SMPコレクターのそれと一致し、シミュレーションの値とも一致している。
VME-TDCコレクターとFERA-UIOコレクターの場合は、不感時間は毎イベントはFERA-UIOコレクターの 60 µsecで、20イベントに 1回はVME-TDCコレクターの 1msecになると考えられる。この値
64
図 5.11: 各コレクターのライブタイムとシミュレーションとの比較。実験データとシミュレーションの値はほぼ一致している。
65
図 5.12: 2つのコレクターをイベントビルダーに接続した場合のライブタイムとシミュレーションとの比較。
66
を用いてシミューレーションで求めたライブタイムの値は、確かにVME-TDCコレクターとFERA-UIOコレクターの結合DAQシステムのライブタイムの値と一致した。全体 DAQシステムのライブタイムについても、今までの考察と同様にして各コレクターの不感時
間の重ね合わせで説明できる。毎イベントは TKO-SMPコレクターの 60µsec、20イベントに 1回はVME-TDCコレクターの 1msecが不感時間として効いているとしてシミュレーションを行えば、その値は確かに全体DAQシステムのライブタイムと一致した。
5.2.3 考察
DAQシステム全体のライブタイムやコレクターのライブタイムはすべて、コレクターの不感時間からシミュレーションして求められる値と一致していた。従って現在の FOREST実験においては、DAQシステムの速度は各コレクターの不感時間すなわちハードウェアからデータを読み出すのにかかる時間によって決定されている。イベントビルダーやレコーダー、またはネットワークは十分に動作し、DAQシステムの律速とはなっていなかった。本実験でのDAQシステムの律速は、TKO-SMPコレクターがデータ収集にかかる時間とVME-TDC
コレクターの 20イベントをまとめて読み出すときにかかる時間になっていた。TKO-SMPコレクターでは、SCHモジュールがADC、TDCモジュールからデータを読み出すときに時間がかかっていることがわかっている。TKO-SMPコレクターで収集しているデータを別のコレクターへと分散することで、TKO-SMPコレクターの不感時間を最大で 100 µsec程度まで高速化することができる。TKO-SMPコレクターで使用しているADCモジュールのデジタルデータ化にかかる時間が 100 µsecである。VME-TDCコレクターでは 12月の実験の時点で 1イベントごとにデータを書き込んで読み出すようにしたため、すでに律速とはなっていない。
5.3 オンラインモニタリング
FOREST実験用に次の機能を備えたオンラインモニターを開発した。
1. Event Sync IDの表示
2. 各検出器のADC、TDC分布の表示
3. 検出器のヒットパターンの表示
5.3.1 Event Sync IDの表示
Event Sync IDは、イベントビルダーがイベントとして構築する各コレクターのデータが正しく同一のトリガーによって収集されたものかを判断するための IDである。イベントビルダーは各コレクターがデータ送信時に作成するイベントナンバーを識別して構築を行う。あるコレクターがデータ収集時にハードウェアの段階でデータを収集し損ねたとしても、データ送信側はそれに気付くことができないのでイベントビルダーは間違ったデータ同士を 1つのイベントとして構築を続けてしまう。これを回避するため、トリガーと同時にハードウェア的にコレクターからは独立した Event Sync IDとなる信号を生成して、コレクターのデータの一部に書き込んでおく。これをオンラインモニターでデータ収集中にリアルタイムに確認することで Event Sync IDがずれて物理的意味の失ったデータを収集し続けることがないようにした。Event Sync IDの確認はトリガーが正しくすべてのコレクターに分配され、すべてのコレクターが正しくデータ収集を行えているかを確認するために重要である。今回のFOREST実験では、Event Sync IDには 4つの信号を用いた。それぞれの信号を各コレクター
の VMEの Interrupt & I/Oレジスタもしくは TDCモジュールの 4つのチャンネルに入力できるよう
67
にし、それぞれの信号の有無で 24 = 16パターンの Event Sync IDをあらわすようにした。オンラインモニターは、各コレクターの Event Sync IDが一致しなかった場合に標準出力で Event Sync IDを表示し、データ収集中にイベントずれが発生したときにすぐに気付けるようにした。
5.3.2 各検出器のADC、TDC分布の表示
もっとも基本的なデータ解析として、データから SCISSORS IIIと Backward Gammaを構成するすべての検出器の ADCデータと TDCデータを読み出し、ヒストグラムを作成して表示した。表示にはPAWを用いた。PAW（Physics Analysis Workstation）は CERN（欧州原子核研究機構）で開発された高機能なグラフ化ツールである。オンラインモニターは受信したデータを解析してADCまたはTDCのヒストグラムを表示する。どのADC、TDCチャンネルがどの検出器のデータに対応するかは、別にチャンネルマップと呼ばれるファイルを作成しており、それを読み込んだ。図 5.14、図 ??に表示したヒストグラムの例として、SCISSORS IIIの検出器 001と 002、Backward Gammaの検出器 000と 001のADC分布、TDC分布を示す。
図 5.13: オンラインモニターで表示させた ADC分布の例。赤線で上書きしてあるのが TDCデータがあったときのADC分布。
各検出器のADC、TDCデータを確認することで、すべての検出器のデータが正しく収集できているかを確認する。これにより、もしデータの収集できていない検出器があった場合、すぐに気付いて対応することができる。
68
図 5.14: オンラインモニターで表示させた TDC分布の例。
69
5.3.3 検出器のヒットパターンの表示
各検出器がどのくらいの頻度で反応しているかを調べるため、SCISSORS III と Backward Gammaを構成するすべての検出器について、TDCデータがあった個数をヒストグラムに書き出して表示した。表示には pawを用いた。図 5.15にそのヒットパターンを示す。
図 5.15: SCISSORS IIIとBackward Gammaのヒットパターン。上図の横軸1001から1192がSCISSORSIIIを構成する検出器（CsIクリスタル）の番号で、下図の横軸 2000から 2251が Backward Gammaを構成する検出器の番号をあらわしている。
SCISSORS IIIは内側から円を書くようにして番号付けがされていて、内側すなわち前方の検出器ほど検出回数が多くなっていることがわかる。またBackward Gammaは、極角 30◦から 100◦までを 7個の検出器が方位角方向 360◦を 10◦ずつ 36列で覆っている。ヒットパターンは 7ずつの周期となっていて、Backward Gammaでも前方にある検出器ほど検出回数が多くなっている。
5.4 データ解析
今回開発したDAQシステムによってはじめて、SCISSORS IIIとBackward Gamma のデータを同時に収集することができた。収集したデータから γγ不変質量分布を組んで、π0中間子と η中間子のピークを確認した。
70
5.4.1 クラスタリング
ガンマ線はFORESTを構成しているガンマ線検出器に入射すると電磁相互作用によって電磁シャワーを起こす。電磁シャワーは制動放射や電子対生成を繰り返して広がっていくので、隣接する複数の検出器に浸みだす。ガンマ線検出器では、検出器に入射したガンマ線のエネルギーを電磁シャワーで発生した荷電粒子によるシンチレーション光の量によって測定する。ガンマ線検出器に入射したガンマ線のエネルギーを正しく測定するためには、電磁シャワーが浸みだした複数の検出器を選び出す必要がある。この操作をクラスタリングといい、クラスタリングによって選び出された複数の検出器をクラスターと呼ぶ。クラスタリングは、
1. TDC情報がある検出器を選出し、新規のクラスターとする
2. 1で選出された検出器に隣接する検出器で、TDC情報がある検出器をクラスターに入れる
3. 1と 2で選出された検出器に隣接する TDC情報がない検出器をクラスターに入れる
という方法で行われる。図 5.16に SCISSORS IIIでのクラスタリングの例を示す。
図 5.16: SCISSORS IIIでのクラスタリングの例。赤色の検出器がTDC情報のある検出器、青色の検出器がTDC情報のある検出器に隣接したTDC情報のない検出器をあらわす。赤色と青色の検出器をあわせて 1つのクラスターを形成している。Backward Gammaでのクラスタリングも同様に行った。
5.4.2 クラスターのエネルギーと位置
ガンマ線のエネルギーは、クラスタリングされた複数の検出器のエネルギー和として算出する。クラスターを構成する検出器の数を nclsとすると、ガンマ線のエネルギー Eは
E =ncls∑i=1
Ei (5.2)
であらわされる。ここでEiはクラスターを構成する各検出器に投与されたエネルギーである。
71
ガンマ線の入射位置は、クラスターを構成する各検出器の位置と各検出器に投与されたエネルギー重心を用いて算出する。クラスターを構成する各検出器の前面中心座標を x⃗i とすると、ガンマ線の入射位置 x⃗は
x⃗ =
ncls∑i=1
Eix⃗i
ncls∑i=1
Ei
(5.3)
であらわされる。
5.4.3 γγ不変質量
π0中間子は 99%の確率、η中間子は約 40 %の確率で 2つのガンマ線に崩壊する [14]。2つのガンマ線のエネルギーをE1、E2、運動量を P⃗1、P⃗1とするとき、崩壊前の粒子の質量は相対論的に、
Mγγ =√
(E1 + E2)2 − (P⃗1 + P⃗2)2 (5.4)
とあらわされる。ここでE1、E2には § 5.4.2で算出したエネルギーである。ガンマ線の質量は 0であるから、
| P⃗γ |= Eγ (5.5)
である。これより γγ不変質量は
Mγγ =√
2E1E2(1 − cos θ12) (5.6)
となる。ここで θ12は 2つのガンマ線の開口角である。§ 5.4.2で算出したガンマ線の入射位置 x⃗1、x⃗2を用いると、開口角 θ12は
cos θ12 =x⃗1 · x⃗2
| x⃗1 || x⃗2 |=
x1x2 + y1y2 + z1z2√(x2
1 + y21 + z2
1)(x22 + y2
2 + z22)
(5.7)
で求められる。ここで x⃗1 = (x1, y1, z1)、x⃗2 = (x2, y2, z2)である。γγ不変質量を組むイベントの条件として、
1. クラスターが 2つである
2. SCISSORS III、Backward Gammaの前面に設置された荷電粒子識別のためのプラスチックシンチレーターの TDC 情報がない
ことを要求した。クラスターが、
1. FOREST全体で 2つ
2. SCISSORS IIIで 2つ
3. SCISSORS IIIと Backward Gammaでそれぞれ 1つずつ
4. Backward Gammaで 2つ
であったときの γγ不変質量分布を図 5.17 に示す。それぞれの不変質量分布でπ0中間子のピークが確認できた。またSCISSORS IIIとBackward Gamma
で 1つずつ、Backward Gammaで 2つのガンマ線で組んだ γγ不変質量分布では約 500MeV あたりにη中間子と思われるピークらしきものを確認することができた。
72
図 5.17: FOREST実験での γγ不変質量分布。クラスターが SCISSORS III（CsI）にあるか BackwardGamma（BG）にあるかで場合分けして γγ不変質量を組んだ。
73
第6章 まとめ
本研究では、FORESTのデータ収集のためのネットワーク分散型システムとなるDAQシステムの設計を行った。ネットワーク上にプロセスが分散するためプロセス間のデータ、コマンド、ログの流れを効率良く管理する必要があり、
1. データの収集から記録までのデータの流れを管理するデータフローレイヤー
2. ユーザーがプロセスを制御するためにコマンドの流れを管理するプロセス管理レイヤー
3. ログを一括して閲覧するためにログの流れを管理するログ管理レイヤー
の 3つのレイヤーで構成されるDAQソフトウェアを設計した。それぞれのレイヤーで必要となるプロセスを考察して各プロセスの設計を行った。
DAQシステムのデータ収集効率を決定するのはデータの流れを管理するデータフローレイヤーのプロセスであり、その性能次第では全体の設計を見直す必要があるため、データフローレイヤーを管理するプロセスの開発を行った。データフローレイヤーのプロセスとして、
1. ハードウェアからデータを読み出すコレクター
2. 複数のコレクターで収集したデータを 1つのイベントとして構築するイベントビルダー
3. 構築されたイベントをハードディスクに記録するレコーダー
4. データ収集中にリアルタイムでデータを表示するオンラインモニター
の 4つのプロセスを実装した。FORESTのデータ収集を行うためのコレクターである TKO-SMPコレクター、VME-TDCコレク
ター、FERA-UIOコレクターを開発し、本DAQシステムによって加速器のビームを使用したFOREST実験のデータ収集を行った。本DAQシステムにはまだプロセス管理レイヤー及びログ管理レイヤーのプロセスが実装されていないが、実装したデータフローレイヤーのプロセスが FORESTのデータ収集において十分な機能を持っていることを確認した。本実験で測定したDAQシステムのライブタイムはトリガーレート約 1.5 kHzに対して 70%弱であり、
目標値とした 2 kHzで 80 %には及ばなかった。しかしながら、本実験でのDAQシステムの性能はハードウェアからのデータの読み出しにかかる時間で決定されており、実装したソフトウェアによるデータ処理は速度低下とならずに十分に機能していたことをシミュレーションを行うことで確認した。今後は現在開発中であるプロセス管理レイヤーとログ管理レイヤーのプロセスの完成を目指す。本実験でDAQシステム全体の性能をほぼ決定していたのはTKO-SMPコレクターであった。FOREST
実験におけるDAQシステムの今後の課題としては、データ収集効率の改善のためのTKO-SMPコレクターの高速化があげられる。TKO-SMPコレクターでは SCHモジュールのデータ読み出しに時間がかかっていることがわかっており、TKO-SMPコレクターで行っているデータ収集はより高速なデータ読み出しが可能である VMEbusベースのコレクターへと段階的に移行していく予定である。この移行によって、目標のトリガーレート 2 kHzでのデータ収集効率 80%は達成できると考えている。
74
謝辞
本研究を行うにあたり、多くの方々にお世話になりました。ここに深く感謝の意を表します。清水肇教授には、指導教官として本研究を行う機会を与えて頂き、常日頃から気にかけて頂きました。
また、研究に対する心構えや物理の考え方等の大きな視野での物の見方を教えて頂きました。心から感謝しています。笠木治郎太教授には、核理研の施設長として大変お世話になりました。また、問題の捉え方や物理の
豊富な知識等を教えて頂きました。山崎寛仁さんには、実験結果や考察等に対して多くのご助言を頂きました。研究内容を見つめ直すよ
い機会になりました。石川貴嗣さんには、常日頃の研究活動において様々な場面でご指導して頂きました。物事への取り組
み方、問題解決等で数多くのご助言を頂きました。また、コレクターの実装等においては大きくご指導、ご協力して頂きました。大変感謝しています。藤村寿子さんには、研究内容等について新しい視点から数多くのご助言を頂きました。また、修士論
文の執筆においては大変お世話になりました。宮原房史さんには、計算機の使い方等の常日頃の様々な場面でご指導して頂きました。鈴木耕拓さんには、実験現場での回路の調整やモジュールの使用方法等において数多くの場面でご指
導して頂きました。また、コレクターの実装等では大きくご協力して頂きました。感謝しています。橋本亮さん、鍬崎秀三さん、佐藤衛さんには、同じ研究グループとして実験での作業等でご協力して
頂きました。東北学院大学の川野篤さんには、DAQソフトウェアの共同開発者としてプロセスマネージャーの開
発等でご協力して頂きました。東北大学核理研加速器グループの方々には、実験を行う際にビームを調整して頂き、安定したビーム
を提供して頂きました。東北学院大学の坂本泰伸さんには、DAQシステムの設計から実装に至るまで様々なご指導して頂き
ました。また、研究への取り組み方からコンピュータネットワークの知識等においてまで数多くのご助言を頂きました。心から感謝しています。最後に、本研究に関わった全ての方々、多くの場面でご指導して頂いた核理研の方々に深く感謝致し
ます。
75
関連図書
[1] T. Kinoshita et al., Phys. Lett. B 639, 429-435 (2006).
[2] T. Nakabayashi et al., Phys. Rev. C 74, 035202 (2006).
[3] H. Shimizu et al., 東北大学核理研研究報告 (2004), 13.
[4] T. Nakabayashi et al., 東北大学核理研研究報告 (2004), 17.
[5] T.K. Ohska et al., Tko Specification, KEK-85-10 (1986).
[6] Y. Sugaya et al., Nucl. Instrum. Meth. A 437, 68-74 (1999).
[7] I. Alexandrov et al., IEEE Trans. Nucl. Sci. 51, 578-584 (2004).
[8] Y. Sugaya et al., IEEE Trans. Nucl. Sci. 48, 1282-1285 (2001).
[9] Y. Sakamoto et al., IEEE Trans. Nucl. Sci. 49, 3254-3261 (2002).
[10] J. Postel, TRANSMISSION CONTROL PROTOCOL, RFC 793 (1981)
[11] J. Postel, User Datagram Protocol, RFC 768 (1980)
[12] Web: http://paw.web.cern.ch/paw/
[13] Web: http://root.cern.ch/
[14] W.-M Yao et al., J. Phys. G 33, 1-1232 (2006).
76
