Proceedings of the 10th Annual Meeting of Particle Accelerator Society of Japan (August 3-5, 2013, Nagoya, Japan)

SPring-8 における新しい制御フレームワーク MADOCA Ⅱの開発
DEVELOPMENT OF NEW CONTROL FRAMEWORK MADOCA II AT SPRING-8
松本崇博#, A), 古川行人 A), 石井美保 A)
Takahiro Matsumoto #, A), Yukito FurukawaA), Miho IshiiA)A) Japan Synchrotron Radiation Research Institute (JASRI)

Abstract
MADOCA (Message And Database Oriented Control Architecture) was originally developed at SPring-8 on 1995, andhas been successfully utilized in SPring-8 and also in other facilities, HiSOR, NewSUBARU and SACLA for controls ofaccelerator, beam line and data acquisition system in experiments. However, we concluded several expansions in its
functionalities are needed to satisfy requirements in our future upgrades in control systems. Therefore, we developed next
generation MADOCA control framework, MADOCA II this time. In this proceeding, we report on MADOCA II fromthe aspect of the messaging. The main features of MADOCA II are as follows; 1) Variable length data such as a waveform
data and an image data can be transferred with a message. 2) Asynchronous controls can be performed for fast processingof multiple controls. 3) Control system can be operated on Windows as well as Linux and Solaris. These functions wereimplemented by replacement of the used messaging library by ZeroMQ. We already started to introduce MADOCA II
for several applications in SPring-8. The status of the replacement of our control system with MADOCA II is also reported.
るドライバーを扱う機会も増えている。現状を鑑みると、MADOCA II のメッセージングにおいて、こMADOCA は 分散制御システムのための制御フ れらの機能が実装されることの意義は大きい。
レームワークであり、1995 年に SPring-8 の加速器や メッセージングの他にもデータ収集とデータ蓄積にビームラインを制御するために SPring-8 において独 関して改良を検討しているが、こちらの状況につい自 に 開 発 さ れ た [1] 。 現 在 で は 、 HiSOR 、 ては[2]を参照されたい。
本稿では、はじめに MADOCA の概要について述
NewSUBARU、SACLA など他の放射光施設におけるべ、現在抱えるさまざまな課題について示す。その制御システムにも利用されている。SACLA では加速器制御と共にビームライン、及び実験ステーショ 後、MADOCA II で拡張された新機能について述べ
ン で の デ ー タ 収 集 (DAQ) の 制 御 に お い て も る。MADOCA II は既にいくつかの事例で SPring-8 のMADOCA が広範囲に適用されており、MADOCA は 制御系に導入されつつある。これらについて紹介すこれら大規模な施設において順調に運用されてきて ると共に、現在、SPring-8 及び SACLA において進められている MADOCA II 制御系への移行に関する状いる。
しかしながら、今後の SPring-8 加速器の高度化や、 況についても触れる。
SPring-8 II における制御系への要求も考慮した際に、MADOCA が現在抱えるさまざまな課いくつかの課題が見えてきた。これらを改善するた 2.
題
め に 次 世 代 の MADOCA 制 御 フ レ ー ム ワ ー ク 、MADOCA II を開発した。本稿では MADOCA II のMADOCA における制御の概略図は Figure 1 に示さメッセージングにおいて新しく拡張された以下の項 れる。制御命令を行う GUI(Graphical User Interface)部目に重点を置いて述べる。と 、 ハ ー ド ウ ェ ア を 制 御 す る EM(Equipment1.

はじめに1.
2.

可変長データへの対応
制御用端末とフロントエンド計算機間の通信の非同期化
Windows による制御

3.

近年、加速器のビーム診断等においては、波形データやカメラ画像など多様なデータを扱うことが日常になってきており、制御における可変長データへの対応が重要になってきている。また、扱う機器の多様性が増加し、Windows でのみ扱うことができ___________________________________________# matumot@spring8.or.jp

Manager)部のレイヤーがそれぞれ分離されている。
GUI が設置される制御用端末(クライアント側)と、EM が設置されるフロントエンド計算機(サーバー側、主には VME) は複数あり、ネットワーク通信を介してこれら分散化されたシステムを制御できるようになっている。
GUI 側からの機器への制御指令は人間が理解しやすい SVOC 形式のメッセージを経由して送られる。
例えば V/O/C = get/sr_rf_cavity/voltage のメッセージの場合は、Verb(動作)が get、Object(制御対象の機器名)が sr_rf_cavity 、Complement（状態の問い合わせ）が voltage となる。S は問い合わせ先を示し、(プロ- 14 -Proceedings of the 10th Annual Meeting of Particle Accelerator Society of Japan (August 3-5, 2013, Nagoya, Japan)

Figure 1: The software structure of MADOCA.
セス番号)_(アプリケーション名)_(ユーザー名)_(ホスト名)から構成され MADOCA 側で割り当てられる。
この問い合わせは始めに同一ホスト内の MS(Message Server) が そ の 指 令 を 受 け 取 る 。 次 にAS(Access Server)がメッセージ中の Object 名から宛先 を 判 断 し 、 相 手 側 の ホ ス ト の EM(EquipmentManager)に指令を送る。EM では機器との応答を行いその結果を取得する。返信時はメッセージがO/V/S/C の形で送られる(相手側の Object は返信時には Subject に入れ替わるため)。C には例えば測定値
で あ る ”1.5V” が セ ッ ト さ れ 、 GUI で はsr_rf_cavity/get/S/1.5V の結果を受け取ることになる。 MADOCA ではこのように SVOC のメッセージ方式により直感的でわかりやすい制御を行うことができる。ユーザーはさまざまな機器の制御をMADOCA の統一的な枠組みを用いて容易に構築することができるメリットがある。しかしながら、長年 MADOCA をさまざまな施設における制御において運用してきた中で、その機能面についていくつかの課題があることが認識されてきた。以下にこれらについて記す。
り、1 つの送信に対して 1 つの答えが返ってくるように順序化(同期化)されているため扱いやすい。しかしながら、メッセージ送信後に答えが返ってくるまでに次のメッセージを送ることができないため、複数の制御を同時に分散処理させることができな
い。
Windows による制御
 MADOCA は Linux や Solaris での運用を想定して構築された。MS でのプロセス間通信で使われている System V IPC も Unix ラ
イクなシステムでのみ利用できる。このため、ネイティブな Windows 環境上では直接MADOCA を用いた制御をすることができない。現在は Cygwin を利用する、あるいは socket サーバーを介して外部の計算機と間接的に通信する手法がとられている。
制御用端末とフロント計算機間に限定した通信による制限
 MADOCA では各ホストを制御用端末(クライアント側)か、フロントエンド計算機(サーバー側)かどちらかであるかを事前に規定し、その間で通信を行うことを想定している。このため、制御用端末同士、フロント計算機同士の通信を MADOCA の枠組みで行うことができない。
Object 管理の必要性
 AS では Object 名と宛先のホスト名との対応リストを利用しているが、これはデータベースに登録された情報を参照しているた
め、Object を新規に利用する際には登録手続きが必要となる。また、通常、機器グループ毎(電磁石、RF、真空等)の Object をまとめて扱うように特化された AS をホスト内にいくつか立ち上げて運用していることから、MS が各 Object をどの AS に配信するかを定義する必要がある。このための設定ファイルの管理も必要となり、二重の手間がかかっている。

SVOC メッセージ長の制限
 MADOCA では SVOC のメッセージ長は 255文字までという制限がある。このため、波MADOCA II メッセージングにおける機形データや画像データのような可変長デー 3.
能タをメッセージで直接扱うことができない。
現在はメッセージ中にファイル名を指定し、 これら MADOCA に於けるさまざまな課題を克服
そのファイルに可変長データを保存する手 するためには、より柔軟なメッセージングを実現す段をとっている。しかしながら、間接な手 る 必 要 が あ る 。 様 々 な 検 討 を 行 っ た 結 果 、[3]法であるため、余分な処理時間がかかって MADOCA II では ZeroMQ の通信ライブラリを用いおり、また制御の見通しが悪い状況である。 てメッセージングソフトウェアを大幅に書き換えた。
Figure 2 に示されるように MADOCA II ではメッセー
同期型通信による制限
 MADOCA では制御用端末とフロントエン ジング構成が大きく変更されている。各ホストにはMS2 (MADOCA II 用 Message Server)が設置され、任ド計算機のホスト間通信(AS と EM 間)に意の２つのホストにおける MS2 を経由して通信を行
ONC RPC と呼ばれる Remote Procedure Callう。３ホスト間以上でのメッセージのルーティングを用いている。この通信方法は確実性があ は行わない。MADOCA II では AS が配置されていな- 15 -

Proceedings of the 10th Annual Meeting of Particle Accelerator Society of Japan (August 3-5, 2013, Nagoya, Japan)

いが、AS の機能は MS2 の内部に実装されている。
以下、MADOCA II で実現された機能について述べる。






可変長データへの対応
 ZeroMQ では、メッセージを複数回に分けて配信することができる。この機能を活かし、通常の SVOC メッセージと同時に画像データなどの付加データを必要に応じて別途送信させることで可変長データへの対応を行った。メッセージ交換に用いるデータ
は MessagePack[4] を用いてシリアライズ化させ、バイナリデータとして扱っている。
MessgePack は多様なデータフォーマットを効率よくデータをコンパクト化させることができるため、我々の用途に適している。
また、MessagePack ではバイトオーダーの処理も内部で行われるため、異なる計算機間においてもメッセージ交換を問題なく行うことができる。
制御用端末とフロントエンド計算機間の通信の非同期化
 ZeroMQ では非同期形式の通信がデフォルトであるため、MADOCA で問題となっていた同期通信による制限をなくすことができる。非同期制御をより効果的に行うため、EM 部を必要に応じてデバイス毎に分割させることができる設計にした。EM を分割させることにより複数の制御を分散化させ高速処理をさせることができる。他には、特定のデバイスが故障した場合においても残りのデバイスで運用させることで運転の継続性を向上させるメリットもある。
これら非同期制御の利用では、複数のメッセージを一度に送信し、後でメッセージをまとめて受信する場合が想定される。送信と受信間のメッセージの対応関係をつける
ため、各メッセージにはメッセージ番号を割り当て、メッセージ受信時にメッセージ番号を指定することができるようにした。
Windows による制御
 MADOCA II では開発当初 からマルチプラットフォームでの利用を想定してソフトウェアの構築を行っている。ZeroMQ 及びMessagePack もマルチプラットフォーム対応である。MADOCA II メッセージングのプ ロ グ ラ ム は C++ で 書 か れ て お り 、Windows 上においても同一のソースプログ
ラムを Visual C++を用いてビルドすることで利用が可能である。
制御用端末間、およびフロントエンド計算機間のメッセージ通信
 MADOCA II では MADOCA と異なり、各ホストは、必要に応じて、クライアント、またはサーバーとしての機能をもたせることができる。したがって制御用端末とフロントエンド計算機間の通信のみでなく、制御用端末間、フロントエンド計算機間の通信も MADOCA II の枠組みで同様に行うことができる。例として Figure 2 では制御用端末における MS2 間を接続させ、相互に通信できるようにした例を示している。
Object 管理の自動化
 MADOCA II では各 Object の配信先のリストが MS2 内に自動登録されており、この情報を利用してメッセージ配信を行うことができる。これは、各 EM が扱う Object リストを、EM 起動時に同一ホスト上の MS2に登録することで実現している。登録された Object 情報は接続されているホスト間における MS2 にも伝播される。このようにMADOCA II では Object 管理が自動化されているため、データベースによる手続きが不要となり管理の手間を省くことができる。
なお、Object 名のユニーク性は MADOCAと同様 MADOCA II においても要求されているため、Object の２重登録を行うことはできない。

Figure 2: The software structure of MADOCA II
messaging.

4.

MADOCA II の利用例

今 回 開 発 し た MADOCA II メ ッ セ ー ジ ン グ はSPring-8 の制御系においていくつかの事例で導入されてきており、MADOCAII で新しく拡張された機能の有用性が示されている。これらの内容については
本学会資料[5][6]を参照されたい。どのアプリケー
ションでも波形データ、画像データなどの可変長データが MADOCA II の枠組みを用いて制御で直接取り扱われている。[5]の例では、Windows 上において MADOCA II の 制 御 系 が 構 築 さ れ て お り 、Windows 環 境 で の み 制 御 可 能 な 機 器 の 制 御 が- 16 -Proceedings of the 10th Annual Meeting of Particle Accelerator Society of Japan (August 3-5, 2013, Nagoya, Japan)

MADOCA II-LabVIEW インターフェースを用いて実装されている。

Figure 3: An example of the implementation of
MADOCA II messaging at BL36XU. AS2 and
RPC_MS2 interfaces are used to connect controls
between MADOCA and MADOCA II.

5.

MADOCA II 制御系への移行について御用端末の数のほうが少ないこと、運転制御に用いる制御用端末は、混乱をさせるために同一の制御方式に速やかに移行させた方が好ましいこと等が理由として挙げられる。SACLA の実験ステーションにおけるデータ収集系における制御に関しては、この夏の停止期間中に制御用端末側を全て MADOCA IIに置き換える予定である。SPring-8 加速器・ビーム
ライン制御系に関しては、来年の春をターゲットに制御用端末側の MADOCA II 移行の準備を進めている。
一旦制御用端末側を MADOCA II に移行させた後は、フロントエンド計算機を MADOCA II へ適宜移行させていくことで全体の制御系を MADOCA II で置き換えることができる。フロントエンド計算機側
では多様な機器を制御するために、Solaris、Linux、ARM 計算機等さまざまな OS が機器制御に利用されており、これら全ての実行環境において MADOCAII を稼動させる必要がある。MessagePack では gcc4.1以上のコンパイル環境が必須となるため、古いシステムでは今まで利用してきた開発環境を利用することができない場合もあった。このため、必要に応じて MADOCA II 専用の開発環境を整備することで対応を行っている。

6.

まとめ

現在、我々は SPring-8 の加速器およびビームライ
MADOCA の制御フレームワークを ZeroMQ の通ンの制御系を MADOCA II に移行させる計画を進めている。今まで MADOCA で構築されてきた多くの 信ライブラリを用いて大幅に書き換え、機能を拡張した新しい制御フレームワーク MADOCA II を開発
アプリケーションを MADOCA II にスムーズに移行
さ せ る た め 、 MADOCA II で 用 意 し た 関 数 は した。既に、波形データ、画像データなどの可変長MADOCA の関数と後方互換性を持たせている。 デ ー タ の 利 用 、 Windows 環 境 で の 制 御 に お い て
よって基本的には再コンパイル、再リンクをするの MADOCA II が利用されてきており、今後、SPring-8加速器の高度化など、さまざまな側面で MADOCA
みで MADOCA から MADOCA II への移行できる。
MADOCA II を実環境で本格運用するため、昨年 II が活用されていくことが期待される。
夏から BL36XU において MADOCA II の試験導入を行った。このことにより、MADOCA II の運用時の安定性について問題がないことを確認するとともに、 謝辞
制御トラブル時の対処方法も確立することができた。 MADOCA II メッセージングの開発を進めるにあBL36XU における MADOCA II 実装については Figure たり、有益な討論、ご意見を頂いた(公財)高輝度光3 に示される。BL35XU では MADOCA II が導入され 科学研究センター 田中良太郎氏、山下明広氏、籠るが、他で稼働している MADOCA 制御系とも共存 正裕氏、他制御・情報グループの方々に深く感謝致
さ せ る 必 要 が あ る 。 こ の た め 、 MADOCA と します。
MADOCA II 間を接続させる２つの制御インターフェースを整備した。１つは、MADOCA II 用ホス 参考文献
トから MADOCA 用ホスト を制御する際に用いる [1] R. Tanaka et al., “Control System of the SPring-8 Storage
AS2 (MADOCA II 用 Access Server) であり、他はRing”, Proceedings of ICALEPCS’95, Chicago, p.201(1995)
MADOCA 用ホストから MADOCA II 用ホストを制御 [2] 山下明広,他 “MADOCA II データ収集と蓄積システム”,本プロシーディング,MOOS09
する際に用いる RPC_MS2 (MADOCA 側の AS と
MADOCA2 側の MS2 の仲介エージェント) である。 [3] http://www/zeromq.org/[4] http://msgpack.org/
どちらのインターフェースも MADOCA II 側のホス [5] 古川行人他,”MADOCA II-LabVIEW インターフェース
ト上で稼動させる。
を用いた BPM データ読み出しシステム”,本プロシー
制御系全体の MADOCA II への移行については、
ディング,MOOS10制御用計算機(GUI 側)の MADOCA II 移行を先に進め [6] 清道明男他,”SPring-8 蓄積リング 2 次元放射光干渉系計
高度化に向けた MicroTCA 画像処理システムの開発”,る方向で検討している。これは、制御系において制本プロシーディング, MOOS11- 17 -