広島工業大学紀要研究編
第 42巻（2008）pp. 221-225

論

文

データ収集システムのためのデータ空間共有型通信フレームワーク
長 坂 康 史 ・元 山 裕 基(平成19年10月31日受理)

A Shared Dataspace Communication Framework for Data Acquisition SystemYasushi NAGASAKA and Hiroki MOTOYAMA(Received Oct.31,2007)

Abstract
A shared dataspacecommunication framework for dataacquisition systemhas been developed. Theframework helps us to develop thedataacquisition systemeasilyand efficiently. It has been developedon the concept of shared dataspace using a repository. The repositoryhas data and their index keys,
and it can be accessed with easy communication commands, PUT, GET, DELETE, NOTIFY andLINK,bythe component. The data are managed bythe index keyin the repository. The component
can access thedatain therepositorybyspecifying thekeyrelated to thedata. Thenewcommunicationcommands,NOTIFY and LINK,werealso introduced in this framework for amanagement ofthedata
in the repository. The data acquisition system developer can develop thesystem easilyand efficiently
with the shared dataspace communication framework.
Key Words: data acquisition, data management, computer networksて，アーキテクチャスタイルの有効性が確かめられてきて１．はじめにいる［３］。アーキテクチャスタイルはシステムが持つアーキ

高エネルギー物理学実験などの測定器実験で使用されるテクチャの詳細を隠蔽し，コンポーネント間の相互作用のデータ収集システムの効率的な開発は，実験実施におけるパターンを明確にする。

一つの課題である。収集データの大容量化に伴い，データそこで本研究では，データ収集システムの開発の効率化収集システムの規模と複雑度は増加する傾向にある。まを目的として，ネットワーク分散型データ収集システムにた，使用される加速器や測定器の種類，実験の目的や内容共通して必要となるネットワーク通信システムの開発を行によって，データ収集システムに対する要求 は 様々で あうと同時に，データ収集システムに適しているとる。これらのことから，多くのデータ収集システムは，実るアーキテクチャスタイルを構築する。アーキテクチャス

験ごとの専用システムとして開発されているのが現状であタイルを構築することで，通信システムに必要となる機能［１］［２］り，開発の効率化が求められている。

えられが明確になる。本研究では，その機能を実現する通信シス一方，規模や複雑度が増加しつつあるソフトウェアシステムを開発する。また，アーキテクチャスタイルの観点かテムでは，多数のコンポーネントから構成されるシステム

ら通信システムで実現できるコンポーネント間の相互作用をどのように組織化するかというソフトウェアアーキテクのスタイルを明確にすることで，通信システムが適用可能チャの設計に関する問題が重要になってくる。これに関しなシステムを判断することができる。

広島工業大学情報学部情報工学科
日本電気通信システム㈱221長坂康史・元山裕基

から読み取り，そのデータをイベントごとにまとめ，保存

２．ソフトウェアアーキテクチャとスタイルする。

2.1 ソフトウェアアーキテクチャ

ネットワーク分散型データ収集システムでは，システムソフトウェアシステムは規模が大きくなるにつれて，ど内でいくつかに分割されたコンポーネントを，ネットワーのようにコンポーネントを分割し，分割したコンポーネンク上に分散しているノード上に置くことになる。基本的なトをどのように組織化するかといった事が大きな問題に分散型データ収集システムのノードの配置図を図１に示なってくる。これはアーキテクチャレベルの問題である。

す。データ収集の主要な処理はデータリーダやイベントビ

システム全体のアーキテクチャは，その性能やスケーラビルダ，データレコーダ上で主に実行される。データリーダ・リティ，拡張性などの特性に大きく影響を与える。

ノード上では，測定イベントが発生すると，測定器からソフトウェアアーキテクチャは，アーキテクチャ要素のデータを読み取り，イベントビルダ・ノードへ送信する処

構成内容によって定義される。アーキテクチャ要素には，理が行われる。イベントビルダ・ノード上では，データリーコンポーネント，データ，コネクタの３つの種類がある。コダ・ノードから渡されてくる測定データをイベントごとにンポーネントはインターフェースを介してデータの変換機まとめ，それをデータレコーダに渡す処理が実行される。

能を提供する抽象的な構成要素である。データはコンポー

データレコーダでは，イベントビルダから受け取ったデーネント間で転送される情報のことである。コネクタはコンタをデータベース等に保存する処理が行なわれる。そしポーネント間の通信や連携を仲立ちするメカニズムであて，これらのノードに加えて，分散したノードやコンポーる。コンポーネントはコネクタを介してデータを転送す

ネント間の協調動作を制御するコントローラ・ノードや，る。

システム全体の動作状況等をモニタンリングし，動作環境を管理するマネージャ・ノードが必要となる。

2.2 アーキテクチャスタイル

データ収集システムは，システムの開発が完了した後，アーキ テ ク チャに は い く つ か の パ ターン が 見 ら れ る。

その実験装置とともに，長期間使用される場合もある。そ様々なアーキテクチャに見られる性質や様式をパターンとの間に，実験装置の性能向上やデータ量の増加に伴い，シしてまとめ，分類したものがアーキテクチャスタイルであステムの処理性能の強化などが行なわれることもある。こる。アーキテクチャはアーキテクチャスタイルの具体例とのような現状において，データ収集システムには機能の拡見なすことができるが，アーキテクチャスタイルはアーキ張性，カスタマイズ性，スケーラビリティなどが要求されテクチャに含まれるシステムの詳細を隠蔽し，コンポーネる。

ント間の抽象的な相互作用のパターンを明確にする。これによりアーキテクチャのもつ特性が明確になり，アーキテクチャ同士をその特性によって比較検討することが可能になる。基本的なアーキテクチャスタ イ ル に は，パ イ プ＆フィルタスタイルや，クライアント/サーバスタイル，レイヤシステムスタイル，イベントベースインテグレーションスタイルなどがある。
アーキテクチャが要素同士の連携に関する制約を持つのと同様に，アーキテクチャスタイルも要素同士の連携に関する制約を持ち，その制約の集合としてアーキテクチャスタイルして見ることもできる［４］。その場合，スタイルが持図１ 配置図つ制約に新しい制約を加えていくことで新しいスタイルを構築するこができる。

3.2 アーキテクチャスタイルの構築本研究で提案するアーキテクチャスタイル は パ イ プ&

３．アーキテクチャスタイルの構築

フィルタスタイルとイベントベースインテグレーションス

3.1 データ収集システム

タイルを込み合わせたスタイルである。このスタイルの概測定器実験で使用されるデータ収集システムの役割は，略図を図２に示す。

測定器からの測定データを一ヶ所に集めることである。実パイプ＆フィルタスタイルは，フィルタとなるコンポー

験装置内で測定対象となる何らかのイベントが発生するネントをカスケードに繫げていくスタイルである。データと，システムはそのイベントに関する測定データを測定器

収集システムが収集しようとするデータは測定器から読み222データ収集システムのためのデータ空間共有型通信フレームワーク

取ら れ た 後，フィル タ リ ン グ や データ フォーマット の 変

以上のように，このアーキテクチャスタイルでは，パイ換，イベントビルド等の処理を受けつつ，最終的にストプで接続されたフィルタによってデータ収集を行い，イベレージへ保存される。収集されるデータはその過程で，測ントバスを介して，フィルタ間でやり取りされるデータフ

定器からストレージへ向けた一方向のストリームをシステローの制御，コンポーネントの管理が行われる。このアーム内に形成する。本研究のアーキテクチャスタイルはそのキテクチャスタイルに含まれるコネクタ要素は入力ストようなデータストリーム上にフィルタコンポーネントを設リームと出力ストリーム，イベントバス，バスコネクタで置することでデータ収集を行う。また，パイプ＆フィルタある。入力ストリームはフィルタとなるコンポーネントがスタイルはフィルタの追加や置き換えによるシステムの機データを受け取るコネクタである。また，出力ストリーム能強化や拡張が行いやすい。

はフィルタが処理をした結果を出力するコネクタである。
この入力ストリームと出力ストリームを接続することでフィルタ間でのデータの受け渡しが可能になる。また，イベントバスはコンポーネントにイベントを通知する通路になるコネクタである。そして，バスコネクタを使用して，コンポーネントはイベントバスへ接続する。

４．通信システム
4.1 モデル本研究で提案・開発した通信システムはリポジトリスタ

図２ アーキテクチャスタイル

イ ル が ベース に なって い る。リ ポ ジ ト リ ス タ イ ル で は，単純なデータ収集システムでは，パイプ＆フィルタスタ

データを管理しているリポジトリにコンポーネントがアクイルのみに基づいたシステムを構築するだけで十分な場合セスすることにより，コンポーネント間のインタラクショもあるが，少し複雑度が増すと，コンポーネント同士の協ンを実現する。このモデルを図３に示す。

調動作といったパイプ＆フィルタには適さない通信が必要となってくる。これに関して，本研究では，イベントベースインテグレーションスタイルを加えることで対応する。
イベントベースインテグレーションスタイルは，イベントとプロシージャを関連付け，イベントのアナウンスにより，プロシージャを間接的に起動するスタイルである。イ
ベントはイベントバスによってコンポーネントに配信されるが，コンポーネントはこのイベントバスを介してパイプ＆フィルタのデータフローの制御等を行う。また，デー
図３ 通信システムのモデル

タ収集の開始や停止といったシステム全体に対する動作の指示や，各コンポーネントやノードの動作状況のモニタリ

このモデルでのリポジトリは，キーとデータを関連付けングもこのイベントバスを介して行う。

ることで，データを管理している。コンポーネントはリク

通常のイベントベースインテーグレーションでは，イベエスト/レスポンス形式の通信をリポジトリと行うことでントを配送するイベントバスは１つだけである。そのたデータにアクセスする。このとき，リクエストの際にキーめ，イベントバスに接続するコンポーネントの数に関してを指定することで特定のデータにアクセスすることができスケーラビリティの問題がある。本研究で定めるアーキテる。データへのアクセスにより，データの取得，作成，更クチャスタイルでは，イベントベースインテグレーション

新，削除といった操作が可能である。

スタイルにレイヤーシステムのスタイルを付加させて，イコンポーネントはリポジトリとのリクエスト/レスポンベントバスを階層的に置くことができるようにする。このス形式による通信以外に，イベントと呼ばれるリポジトリため，イベントバス同士を仲介するメディエイターコンからの通知を受けることができる。この仕組みを使うことポーネントがスタイルに追加される。イベントバスを階層で，データへのアクセスによりデータの作成や更新が発生的に設置できるようにすることで，ネットワーク通信の効すると，その通知を受けられるようにすることができる。

率を高めることができ，スケーラビリティを確保することができる。
223長坂康史・元山裕基

4.2 機能4.3 コネクタの構築方法

本研究で開発した通信システムは前述のモデルに基づい本研究で構築したアーキテクチャスタイルのコネクタ要た機能を持っている。通信システムのリポジトリが管理し素は，入力ストリーム，出力ストリーム，イベントバス，バているデータはシリアライズ/デシリアライズ可能な任意スコネクタである。これらのコネクタは本研究で開発したのオブジェクトである。このデータを関連付けているキー

通信システムを用いて構築することができる。基本的にには文字列を使用している。通信システムが提供する機能

は，各コンポーネントが１つずつリポジトリを持ち，お互は，Get，Put，Delete，Notify，Link の５つである。

いが持つリポジトリにアクセスすることでコネクタを構築

Get はリポジトリにあるデータを取り出す機能である。

する。

Get リクエストをリポジトリに出すことで，この機能を利

入力ストリームはリポジトリのキーに対して Notifyの用できる。キーを指定して Get リクエストをリポジトリへ設定をするだけで構築できる。Notifyの設定をしたキーに出すと，そのキーに対応するデータがレスポンスとして返対してデータの作成・更新があるとそれが変更内容と共にされる。キーに対応するデータが無い場合，リクエストの通知される。変更が発生するごとにその順番を維持して通処理はリポジトリ上でブロックし，データが作成されるま知が行われ，バッファリングされるため，これは入力ストでレスポンスは返されない。ただし，Get リクエストにタイリームの役割を十分に果たしている。出力ストリームはリムアウト時間を指定すると，ブロックする時間は最長でそポジトリのキーに対して Put リクエストを出すだけで良のタイムアウト時間までとなる。Put はリポジトリにあるい。出力ストリームと入力ストリームは互いに接続されるデータを作成・更新する機能である。Put リクエストをリポことでその役割を果たすことができる。両者の接続には，ジトリに出すことでこの機能を利用できる。キーを指定し出力ストリームと入力ストリームを識別するキーを同一リてデータと共に Put リクエストを出すと，指定したキーにポジトリの同一のキーにする。もしくは，キー同士を Link対応するデータの作成，または更新が，Put リクエストと共で接続する。これにより，出力ストリームでの Put によるに渡したデータを用いて行われる。

データの変更が Link や Notifyにより伝達され，出力スト

Delete はリポジトリにあるデータを削除する機能であリームから入力ストリームへとデータが受け渡される。

る。Delete リクエストを出すことでこの機能を利用できイベントバスとバスコネクタはリポジトリそのものがそる。キーを指定して Delete リクエストを出すと，リポジトの役割を果たす。イベントバスに対して受信したいシグナ

リはそのキーに対応するデータを削除する。キーに対応すルを登録するには，イベントバスになっているリポジトリるデータが無い場合は何もしない。に Notifyの設定をする。このとき指定するキーがシグナルリポジトリは，データの作成，更新，削除のいずれかがの種類を表している。シグナルを送信するには，送信した起こると，それをイベントとして捉える。Notifyはそのイいシグナルの種類を表しているキーに対して Put リクエ

ベントが発生した時，それを通知する機能である。この通ストを送る。Put リクエストによるデータの変更によって，知の設定を行うには，リポジトリに Notifyリクエストを出その通知がシグナルを受信したい全てのコンポーネントへす。キーを指定して Notifyリクエストを出すと，リポジト送信され，シグナルの送信が完了する。

リは NotifyID をレスポンスとして返す。リクエストで指定したキーに対応するデータに作成，更新，削除のいずれ4.4 性能評価かが行われると，そのイベントの種類と NotifyID が通知開発した通信システムを入出力のストリームとして使用される。また，データの作成か更新によってイベントが発したときのスループットと，イベントバスとして使用した生した場合はそのデータも通知される。

ときのシグナル配信の遅延を測定した。

Link は同一リポジトリ，または異なるリポジトリにある

測定には２台の PC を用意し，前述したコネクタの構築２つのキーを関連付ける機能である。Link はリンク元キーを行った。測定に使用した PC のスペックを表１に示す。入からリンク先キーへの方向を持ち，リンク元キーに対応す

出力ストリームとシグナルで送受信するデータには，単なるデータの作成，変更，削除があった場合，それと同様のるビットの塊と整数の配列の２種類を使用している。単な処理がリンク先キーに対応するデータにも行われる。

るビットの塊では，送受信の際にシリアライズ/デシリアラ

Link の設定を行うには，リンク元のリポジトリに Linkイズが不要であり，システム本来の性能を知ることができリクエストを出す。このリクエストには，リンク元キーとる。整数の配列では，シリアライズ/デシリアライズの処理リンク先のリポジトリ，リンク先キーを指定する。

が必要であり，それには要素の数に比例する時間がかかる。この２つの測定結果の比較により，データの種類による性能の影響を見る。
224

データ収集システムのためのデータ空間共有型通信フレームワーク

けでなく，パイプやイベント通知の通信形式が適している

表１ マシンスペック

システムにこの通信システムを利用することが可能であるとえられる。

入出力ストリームのスループットの測定結果を図４に，シグナルの遅延を図５に示す。両グラフにある network
performance の値は通信システムを使用せずに測定した，ネットワークのスループット性能と，ターンアラウンドタイムである。スループットの測定結果を見てみると，単なるビットの塊（raw data）の値はデータサイズ１kB 以上では，ネットワークの性能に近いスループットが出ているこ
図４ パイプのスループットとがわかる。データ収集システムで収集するデータは１kB未満のサイズのものは少ないことから，スループット上の問題は少ないとえられる。遅延の測 定 結 果 で は，rawdata と network performance を比較すると，データサイズが１ kB 以下であるときに遅延の増加が比較的大きく，その差は約 1.2ms である。イベントバスを流れるデータは１kB 以下のものが多いときな問題になるとはえられるが，1.2ms の差が大えにくい。

送受信するデータのタイプによる性能の影響を見てみると，データサイズが小さいときにスループットの影響が大
図５ イベントバスの遅延きく，また，データサイズが大きくなるほど遅延への影響が大きいことがわかる。このことか ら，データ の フォー

参マットやシリアライズ/デシリアライズの方法等が性能改善の重要な要素であるとえられる。

文

献［１］ J.Gutleber,et al.:“Towards a homogeneous architecture for high-energy physics data acquisition sys-５．まとめ

tems,”Comp.Phys.Comm,Vol.153,pp.155‑163,2003

本研究では，データ収集システムの開発の効率化を目的［2］ Y.Skamoto, et al.:“KONOE:An object-oriented /として，ネットワーク分散型データ収集システムに共通しnetwork-distributed online environment,” IEEEて必要になる通信システムの開発を行った。通信システム

Trans. Nucl. Sci. Vol. 49, pp.3254‑3261, 2002の開発にあたって，データ収集システム用の アーキ テ ク［3］ D.Galan and M.Shaw: “An Introduction to Soft-チャスタイルを構築し，データ収集システムに必要な通信

ware Architecture,”Advances in Software Engineer-形式を明確にした。その通信形式はパイプとイベント通知

ing & Knowledge Engineering, Vol. 2, pp.1‑39, 1993である。本研究では，その通信形式をサポートするよう通［4］ Roy Thomas Fielding: “Architectural Styles and信システムを開発した。このアーキテクチャスタイルをも

the Design of Network-based Software Architec-

つデータ収集システムの開発を行う際，本研究で開発した

tures,”PhD thesis, University of California, Irvine,通信システムを利用することができ，開発の効率化を図る

2000

ことができるとえられる。また，データ収集システムだ

225