DEVELOPMENT AND IMPLEMENTATION OF EPICS CHANNELACCESS CLIENT WITH REAL-TIME WEB USING WEBSOCKET
Akito Uchiyama #,A), Kazuro FurukawaB), Yoshihide Higurashi c)A) The Graduate University for Advanced Studies, School of High Energy Accelerator Science (Sokendai)
1-1 Oho, Tsukuba, Ibaraki, 305-0801
B) High Energy Accelerator Research Organization (KEK)
1-1 Oho, Tsukuba, Ibaraki, 305-0801
c) RIKEN Nishina Center
2-1 Hirosawa, Wako, Saitama, 351-0198

Abstract
In the large experimental facilities such as KEKB, RIBF, and J-PARC, the accelerators are operated by the remotecontrol system based on EPICS (Experimental Physics and Industrial Control System). One of the advantages in EPICSbased system is the software reusability. Because it is available to develop client system by using Channel Access (CA)protocol without protocols with hardware dependencies, even if the system consists of the various kind controllers. As
next-generation OPI (Operator Interface) using CA, we develop a server for the WebSocket, which is a new protocol
provided by Internet Engineering Task Force (IETF), with combination of Node.js and the modules. As a result, we areable to use Web-based client system not only in the central control room but also with various types of equipment foraccelerator operation.

WebSocket を用いた EPICS Channel Access Client の開発と実装ークだけでなく、WAN を利用してシステムを提供する事が技術的には可能になる。エンドユーザはイ
EPICS を用いた制御システムの長所の一つとして、 ンストールする事無しにシステムを利用できるので
各 コ ン ト ロ ー ラ に 用 い ら れ る 通 信 プ ロ ト コ ルは X Window System 環境や専用ソフトウェアをインスEPICS IOC (Input/Output Controller) によって CA プ トールする必要は無くなる。
現在の社会一般において Web 及びそのネットワーロトコルとして統一して扱われる、という事が挙げ
クは、すでにインフラの扱いであり、PCだけでなられる。よって OPI をはじめとしたクライアントシ
く携帯電話、テレビ等、様々な機器にブラウザが実ステムは CA プロトコルに基づいて開発を行えば良装され Web を利用する事が可能である。よってい事になる。
OPI 開発には C/C++、Python や Java 等でコーディ Web に対応さえすれば将来的にはプラットフォームングする手法や、MEDM/EDM・CSS (Control System に限定されず、PC だけでなく様々な機器が制御端Studio) /BOY [1] といったディスプレイマネージャを 末として利用する事が可能になるはずである。専用用いてコーディング無しに GUI を構築していく手法 端末が必要無くなるという事は、同時にシステムリを取ること事が一般的である。一方 SPring-8 では実 プレース時のコストを大幅に抑える事も可能になる
験用ビームライン制御用に新しい Web の規格である という事にもなる。
また、Web 技術を使用した場合におけるシステム
WebSocket を用いた OPI の開発手法を考案し、プロ[2]開発の簡便さも挙げられる。一般的にHTML とトタイプの実装が行われた 。SPring-8 の制御シス
JavaScriptでの構築はC/C++やJavaのそれと比べた
テ ム は 独 自 に 開 発 し た MADOCA (Message And
Database Oriented Control Architecture) をベースに構 場合、容易でかつ開発速度が速い。例えばクライア
築 さ れ て お り 、 EPICS の そ れ と は 異 な る 。 ント開発において、本質的な機能ではない GUI の開WebSocket を用いた Web アプリケーションとシステ 発は多くのリソースが必要になる工程である。ヒュムの利点を重要視し、我々は EPICS CA に対応する ーマンリソースが多くない加速器施設にとっては大WebSocket 用サーバの開発とクライアントの実装を きなメリットになり得る。

1.

はじめに行った。

2.

Web を用いたアプリケーションの利点

現在まで様々な Web を用いた加速器制御システムの開発が報告されている。加速器制御に Web 技術を用いる事の長所は次の通りである。
Web を用いる事で限定されたローカルなネットワ#a-uchi@riken.jp

3.

従来の EPICS における Web システム

ここで、比較のため、Web 技術を利用したこれまでの EPICS 向けオペレータ インターフェース機構について、概要を見てみる。
3.1

CAML

CAML (Channel Access Markup Language) は XMLベースの言語で動作仕様を記述する事でブラウザから CA 通信を経由した制御を可能とするフレームワークである [3] 。プラグインとして Firefox, Google
Chrome, Safari に組み込む事でブラウザが CA で通信を行う。直接ブラウザが CA 接続を行うのでネットワーク上にあるゲートウェイやファイヤーウォールを越える事は難しい。よってローカルな環境で運用する事が必須であると思われる。
3.2

PHP EPICS Module

PHP で書かれた Web アプリケーションにサーバサイドから EPICS CA をさせる為のモジュールである [4] 。PHP は Web アプリケーションを実装できる
サーバサイド言語であるが、動的な Web アプリケー
シ ョ ン を 開 発 す る為にはクライアント側に Ajax
(Asynchronous JavaScript XML) で DOM (Document
Object Model) 操作を行う JavaScript が必要になる。
なお、最近のシステム・ソフトウェアに対応させた新版の案内は無い。

い制御に限られてきた。何故なら従来の HTML 技術
ではサーバ側とクライアント側の双方向通信ができない為ネイティブなアプリケーションの様なリアルタイム応答性の確保が難しかったからである。ここで言う”リアルタイム”とは人間が判断する上でディレイが無い、もしくは極めて小さい事を意味する。
WebSocket を用いればサーバ・クライアントでコネクションを維持したまま双方向に通信する事が可能になるので上記問題は解決する。実際に WebSocketを用い 100 msec 周期程度で変化する値であればMEDM/EDM と遜色ない動作を有する事を確認した。
また Comet/Ajax の様に定期的に polling する必要がないのでネットワークトラフィックやコネクション数を減らす事が可能になる。問題点は全てのブラウザが対応しているわけではない点で主要ブラウザでは Internet Explorer (IE) 9 が未対応である。しかし次期バージョンである IE10 では WebSocket 対応が予定されている [9] ため時間が解決してくれる問題とも言える。

5.

開発手法

3.3

WebOPI
5.1 サーバサイド
WebOPI とは CSS/BOY で開発した GUI パネルをWebSocket サーバの開発には Node.js [10] とそのラWeb で提供させるアプリケーションである [5] 。サ
イブラリである Socket.IO [11] を利用した。Node.jsーブレットコンテナに Tomcat7 が必要で、バックエは Google V8 JavaScript Engine [12] を元に開発された
ンドに Eclipse の RAP (Rich Ajax Platform)[6]を利用しサーバサイド JavaScript の一つである。シングルスている。CSS/BOY で開発したアプリケーションが レッドベースな非同期処理の仕組みを持つ事が特徴
ソースに手を加えずにコンパチブルにブラウザ上で と し て 挙 げ ら れ る 。 本 開 発 に お い て 非 同 期 な動作するので非常に有用である。動的な動きには WebScoket サーバを実装するには多くのリソースがAjax を用いており、通信トラフィックを減らす為に 必要になると思われたが、Socket.IO が上記問題を解JSON (JavaScript Object Notation) でデータを一括送 決した。現在同じように WebSocket 機能を提供する[13]]
信している。しかし変化がないレコードに関しても ライブラリは C 言語では libwebsocket 等がある。
データとして送信するので、その点には無駄がある。 開発された WebSocket サーバはイントラネットだけ
我々のテストではイントラネット環境において~100 でなく、将来的な WAN からのアクセスを考慮してWebSocket に対する SSL と認証の機能をオプション
msec の周期でデータ取得できる事を確認した。しかで持たせている。開発に使用したバージョンはステ
し 500 msec 遅延がある環境にある(日本から SNS のーブル版である Node.js 0.6.18、Sockt.IO 0.9.6 を用い[7]サーバに接続) WebOPI のデモページ では Web 上 た。の値の update 間隔が長くなり性能が落ちる。
5.2 Channel Access for Node.js

4.

WebSocket

CA と通信を行う事が可能な WebSocket サーバをNode.js
で実装する為には Node.js から CA プロトコ
WebSocket とはサーバ・ブラウザ間で双方向通信[8]を実現する為のプロトコルである。当初 HTML5 ルが呼べなければならない。したがって CA をインの仕様の一部であったが、独立した仕様になりドラ ターフェースする Node.js のアドオン、NodeCA を開フト版を経て、2011 年 12 月に ITEF より RFC6455 発した。Node.js は C++で開発した関数をモジュールとして策定された。プロトコルの概要は以下である。 として呼ぶ事が可能なので EPICS base で提供されて1. ブラウザが WebSocket の接続をする為にハン い る CA library を NodeCA では利用している。
ドシェイクの要求をサーバに送る。
Node.js から CA を扱う為に用意した主な関数には、2. サーバは承認後ブラウザにハンドシェイクの基本的な機能である caGet, caPut, caMonitor がある。
レスポンスを返す。
3. ハ ン ド シ ェ イ ク 確 立 後 プ ロ ト コ ル が イベントドリブンな動作をする caMonitor は何も考WebSocket に切り替わり、以後サーバ・ブラ えずに実装するとシングルスレッドで走る Node.js
においてブロッキングの原因となってしまう。これウザ間で双方向通信を行う。
今まで Web を利用した CA クライアントが実装さ を防ぐ為に caMonitor のイベント待ちの関数を別スれてはきたが、ある値のモニタや速い応答が必要な レッドにする事で対応した。概略を図１に示す。現在 NodeCA は Array (ca_array_get, ca_array_put) に対応できていないので今後実装する予定である。

図１：NodeCA における caMonitor 関数の概略
5.3

クライアントサイド

テ キ ス ト の 単 純 な 値 の 変 更 (text update) は
JavaScript で DOM 操作を記述する事で対応できる。
その他、情報視覚化の為に jQuery[14]をベースとしたJavaScript ライブラリである flot[15]と jsgauge[16]を利用した。上記以外にも JavaScript で利用できる情報視覚化のためのライブラリは有償・無償ともに選択肢は多く、通常であればコストがかかる工程を容易に行える事は大きなメリットである。
5.4

6.

実装

ブラウザやシステムにおける対応状況を表１に示す 。 な お iPhone4S, Android 端 末 に お い て も
WebSocket 経由で CA から値を取得、表示できる事を確認した (図４)。iPhone を利用する場合、自ら開発したアプリケーションを Apple Store を通さずにインストールする事は簡単ではない。しかし Web アプリケーションであればその必要は無く、本成果物を利用する事で対応可能であると考えられる。
現在、理研 RIBF における 28GHz 超伝導 ECR イオン源[17]の制御でテスト的に実装を行っている。ガスバルブ・ロッド(試料)位置の駆動制御、 真空値のモニタに関して良好なレスポンスを確認しており、実運用に向けて開発が続けられている。
表１：2012/07 現在における本システムの対応を確認した主要ブラウザ状況
Windows/Linux

Google Chrome 20
Firefox 14
Opera 11

システム概要Android 4.0

全体のシステムチャートを図２、開発した
NodeCA の概要を図３に示す。クライアントサイド
JavaScript 内で Socket.IO のカスタムイベント(caGet,caPut, caMonitor, etc) を WebSocekt でサーバに投げる事で EPICS IOC からデータを取得する。本研究で開発された部分は灰色部分で表す。

Google Chrome 18
Firefox 14

iOS (iPhone)

Safari 5
Google Chrome 19
Mercury

図２：全体のシステムチャート
図４：開発中の 28GECR イオン源制御用 GUI パ
ネ ル を 表 示 さ せ て い る Android 端 末 ( 左 ) とiPhone 端末(右)7.

図３：開発した成果物の概要

考察

将来的には WAN からの加速器ネットワーク内への装置に対して WebSocket 制御を可能にさせる事で加速器運転支援システムという位置づけを目指している。例えばビームオペレーションや実験中に、ある機器・装置に対して熟練者の極めてシビアなチューニングが必要になるケースがある。その時に担当者が海外出張や深夜で不在であれば、対応が遅れ最悪の場合実験自体円滑に進まないケースもある。以上を実現する為の考察を行った。
まず悪意ある外部からの侵入を防止する為には次の様に考える。ローカルなネットワーク内のサーバアクセスは VPN を用い、WebSocket については SSLと認証でセキュリティを確保する。また現場オペ
レータはどこから(どこのインターネットサービスプロバイダか) 誰がアクセスしてきたかを完全に把握しなければならない。よって加速器オペレータには
WebSocket サーバのアクセスログを完全に公開する必要がある。
次にブラウザから WebSocket 経由での EPICS IOCへの命令について考える。各機器の動作に関する命令である”caPut”については現場加速器オペレータが完全に把握する必要がある一方、単純な機器からの値 の 取 得 や モ ニ タ の 為 の 命 令 で ある”caGet”、”caMonitor”についてはその必要はないと考える。何故ならビームチューニング中にもかかわらず、勝手に他の機器を制御されてしまうと、ビームへの影響がどのオペレーションによってなされたか現場加速器オペレータが混乱、判断不能に陥るからである。よって caPut に関しては現場オペレータと遠隔制御者の間で厳格なポリシーが必要である。
ポリシーについて以下を提案する。
1.

2.

3.
4.

5.

6.
7.とタイムアウトで遠隔制御の許可は取り消される。
caPut 制御の可否における具体的な仕組みについては様々な手法が考えられるが、その内の一つは CAGateway[18] の様なパケットフィルタリングを動的に行い対応させる手法がある。

8.

まとめWebSocket で CA 接続を可能にさせる為のサーバを開発し、ブラウザからリアルタイムに加速器の情報 を 表示させる事が可能になった 。Node.js から
EPICS Channel Access を呼ぶ為のアドオン NodeCAを開発する事で実現した。現在、実運用に向けて最初のバージョンをリリース、テスト的に実装、制御を行っている。理研 28GHz SC-ECR イオン源の一部のコンポーネントについてネイティブなアプリケーションの様にモニタ、制御可能である事を確認した。
将来の WAN からのアクセスを実現させる為のアクセスポリシーも検討中である。

9.

謝辞

本開発を進めるにあたり SPring-8 の古川行人氏には意見交換の機会と貴重な助言をいただきました。
ここに感謝します。

10. 参考文献[1] X. Chen, et al., Proceedings of 2011 Particle Accelerator
Conference, New York, NY, USA, 2011, WEOBN3[2] Y. Furukawa, et al., Proceedings of ICALPECS2011,
遠隔制御者は電話もしくは E-mail で今から接Grenoble, France, 2011, WEMAU010
続して遠隔制御を行いたい旨をオペレータに [3] T. Pelaia II, et al., Proceedings of ICALPECS2009, Kobe,Japan, 2009, FRA001
伝える。
[4] A. Bertrand et al., Proceedings of 10th ICALEPCS, Geneva,
遠隔制御者は制御したい GUI の Web へ SSL
Swiss, (2005), P3_087.
で接続しユーザ ID、パスワードで認証を行う。 [5] K. U. Kasemir, et al., Proceedings of ICALPECS2011,
Grenoble, France, 2011, THBHAUST01
認証後は WebSocket でモニタできる。
オペレータは遠隔制御者がどこから、どの [6] http://www.eclipse.org/rap/[7] http://sourceforge.net/apps/trac/cs-studio/wiki/webopi
ユーザ ID で接続してきたかを確認する。
[8] I. Fette and A. Melnikov. The WebSocket Protocol, IETF
HyBi Working Group. 2011.
遠隔制御者は WebSocket で caPut したい機器のレコードに対して現場オペレータへリクエ [9] http://msdn.microsoft.com/en-us/library/ie/[10] http://nodejs.org/
ストを送る。
[11] http://socket.io/
オペレータは遠隔制御者からのリクエストに [12] http://code.google.com/p/v8/
対して、現在それを制御してよいかどうかを [13] http://git.warmcat.com/cgi-bin/cgit/libwebsockets/[14] http://jquery.com/
判断し、可能であるならば許可をレスポンス [15] http://code.google.com/p/flot/として返す。
[16] http://code.google.com/p/jsgauge/
遠隔制御者は許可レスポンスが返ってきたら [17] Y. Higurashi et al., Rev. Sci Instrum. 83, 02A308 (2012)[18] R. Lange, “CA Gateway Update”, presented at the EPICS
モニタだけでなく制御が可能になる。
Collaboration Meeting at JLab, Newport News, Virginia,
オペレータが遠隔制御の中断を判断したら許November 2002.

可を取り消す。取り消すとオペレーションは行えなくなる。また、ある一定時間が過ぎる