DEVELOPMENT OF MONITORING SOFTWARE FOR THE SACLAFACILITY UTILITIESRyosen Fujihara #, Takemasa Masuda , Toko Hirono , Akihiro Yamashita
Japan Synchrotron Radiation Research Institute (JASRI/SPring-8)
1-1-1 Kouto, Sayo-cho, Sayo-gun, Hyogo, 679-5198, Japan

Abstract
This paper presents monitoring software for the SACLA facility utilities. The management system of theSACLA facility utilities consists of a control and data acquisition system and the monitoring software. Since theutilities data such as cooling water temperature for the accelerator, air temperature of the accelerator tunnel andpower line voltage are important for the stable SACLA operation, the utilities data collected by the dataacquisition system are stored into the accelerator database. The monitoring software periodically refers the latest
utilities data on the accelerator database and checks their normality. When the software detects abnormal states bycomparing normal conditions defined in a parameter database, it records the states into the dedicated database andannounces them to the observation staff. The software has a three-level hierarchy structure. The top layer is asmall-sized launcher GUI panel. The second layer is composed of eight summarized GUI panels that are used forordinary observation. 54 panels in the third-layer are launched from the second layer and used for detailed views.
This hierarchy structure facilitates the stuff to watch the entire facility utilities on limited space of a display.

SACLA 施設ユーティリティ監視ソフトウェアの開発
1.

はじめにX 線自由電子レーザー施設(SACLA)では、施設ユーティリティの状態が加速器の性能に与える影響が大きいため、全ての施設ユーティリティ監視デー
タを加速器制御系データベースに収集し、加速器制御系と施設ユーティリティ監視系で監視データを共有出来るようにしている。これにより、監視対象の重複収集を避け、施設全体として効率の良いデータ収集系を構築することに成功している[1]。
我々は、加速器データベースに収集されたこれらの監視データを用いて、施設ユーティリティ監視ソフトウェア（以下監視ソフトウェア）を製作した。
製作にあたっては加速器制御系で使用しているアラーム監視ソフトウェアを参考にし、施設ユーティリティ監視で求められる要件に合わせてカスタマイズを図る手法を採用した。施設ユーティリティの監視ソフトウェアは、一般的に施設の規模に応じて大掛かりになりがちであるが、代表的な警報のみを前面に出し、従属する画面に詳細な警報を表示する階層構造を持った表示方式とすることで、少数の画面で全施設ユーティリティの監視を可能とした。

2.

要件

施設ユーティリティは、加速器の運転状態に関わらず 24 時間、365 日の連続監視が出来なければならない。また、加速器制御系では加速器に関係のある部分のみを監視するのに対して、施設ユーティリティ監視系では全体を監視する必要があるため、異常と判断する対象データやその条件が異なる。従って施設ユーティリティの監視は、加速器運転とは独立に行えなければならない。これらを踏まえ、以下の要件に基づいて監視ソフトウェアの設計を行った。
・加速器運転とは独立に、詳細な監視条件の設定が可能であること。
・加速器施設の運転/停止に応じて監視状態の切り替えができること。
・数枚の液晶モニタ上で SACLA 施設ユーティリ
ティ全体の監視が可能であること。
・警報音による通知が可能であること。
・複数のアナログ入力値（AI 値）を一つのグラフに表示し、経過を同時に把握できること（トレンドグラフ）。
・監視端末の増設が容易であること。

3.

施設ユーティリティ監視系の全体構成

3.1

データ収集系

監視データの収集は、SACLA の加速器棟、挿入
光源棟、XSBT、共同利用実験棟および相互利用実験施設の各建屋とその内部の設備を監視対象とし、第一系統として装置冷却水設備、第二系統としてそれ以外の空調・衛生設備と電気設備を監視する(図1-データ収集)。
加速器冷却装置の温度や流量、電気設備の電力値といった監視データは、監視対象の近くに置かれた
Programmable Logic Controller (PLC)から FL-net[2]を介してメイン PLC に送られ、メイン PLC に接続された VME 計算機上のデータ収集ソフトウェアによって加速器データベースへ蓄積される。
これらデータ収集系を含む施設ユーティリティ制
御システムは 2010 年度に完成した。

___________________________________________#fujihara@spring8.or.jp- 717 -図 1: 施設ユーティリティ監視システム 全体構成

グラフィカルで高い操作性を持った監視ツールを提供するものである。
施設ユーティリティ設備の監視データは加速器監視ソフトウェアは制御系中立ネットワーク上のデータベースに蓄積され、加速器制御系、施設ユー 監視サーバで動作し、同ネットワークを通じて加速ティリティ監視系のいずれからも参照が可能である。 器データベースから必要なデータを取得する（図 1データベースを用いた監視の手法は、加速器制御系 データ表示）。監視サーバは仮想ホスト計算機上にのアラーム監視ソフトウェアを基にしている[3]。
作成された仮想マシンであり、仮想マシンのデスク
加速器データベースの管理システムには Sybase トップ画面は VNC により同ネットワーク上のシンクライアント端末(HP 社製 t5745)の画面に表示されAdaptive Server Enterprise 15.5 を使用している。
る。シンクライアント端末を利用することで監視端末の設置を容易にし、また監視端末の増設による負3.3 データ表示系
荷の上昇に対しては、仮想マシンである監視サーバ
データ収集系のメイン PLC には施設ユーティリ の増設によって対応できるようにした。同ネット
ティ監視業務のための Graphic Panel (GP)が取り付け ワーク上には警報音通知機（株式会社パトライト製られており、警報の表示、警報音出力や一部の監視 NHS-3FB1-RYC）を設置した。
条件の設定が可能であるが、文字表示のみで、また監視用シンクライアント端末は現在、SPring-8 中詳細な監視条件を設定する機能が無い。本件監視ソ 央設備監視室に 2 台置かれており、1 台のシンクラ
フトウェアは、この GP に足りない機能を補完し、 イアント端末で 2 画面表示が可能である。
3.2

データベース

図 2: 監視ソフトウェアとデータベースの関係

4.

監視ソフトウェア

4.1構成監視ソフトウェアは（株）フジデータシステム社
製 X-Mate GUI 構築ツールを用いて作成し、監視サーバ上の SUSE Linux Enterprise Server11 SP1 環境で動作させた。
ソフトウェアの構成は大きく分けて、監視データを判定しアラームを生成する異常監視プロセスと、発生したアラームを表示する画面表示プロセスの二つのプロセスからなる。異常監視プロセスを監視サーバ上で一つだけ立ち上げ、そこで生成されたアラーム情報を他の全ての画面表示プロセスで共有する。
監視ソフトウェアは全監視対象を総計して、AI信号 523 点、デジタル入力信号(DI 信号) 154 点を扱う。DI 信号は一信号が 32bit で構成され、各ビットが一つの監視対象の状態を示す。上記 DI 信号点中827 ビットを監視に使用している。

- 718 -

4.2

異常監視プロセス

異常監視プロセスは、あらかじめ設定された監視周期毎に、オンラインデータベースから監視対象のAI、DI 信号値を取得し、パラメータデータベースから取得した監視条件と比較してアラーム判定を行う（図 2）。オンラインデータベースの信号値は加速器制御系と共有しつつ、一方でパラメータデータベース上の監視条件は監視ソフトウェア専用のテーブルに収められているため、施設ユーティリティ監視系側で独立して監視条件を定め、異常監視を行うことが出来る。
アラーム判定の方法は AI 値、DI 値により異なる。
AI 値の場合、測定値に対する上限値、下限値、また上下限値の組み合わせ、基準値との差、基準値との乖離率などのうち、信号の性質に応じていずれか一つの方法で判定され、設定されたしきい値から外れていればアラームとなる。アラームレベルは注意喚起、軽故障、重故障の三段階があり、それぞれにしきい値が設定され、機器の異常の度合いによりアラームレベルが遷移する。アラームレベルのうち注意喚起は、加速器制御系のアラーム監視ソフトウェ
アには無く、本件で新たに追加された警報レベルであり、故障発生前の事前対応を目的としている。
DI 値の場合、現在値と正常値のビットパターンを比較し、相違がある場合には異常となる。判定方法はこの一パターンのみである。判定は同種の機器の状態をひとまとめにして、一信号単位（32 ビット）で行われる。加速器制御系のアラーム監視ソフ

図 4: 状態表示画面（第二階層、加速器空調･冷却- 719 -

図 3: 監視ソフトウェア画面構成図

図中のオレンジ色が警報）トウェアでは、警報も信号単位で生成していたが、 データベースからアラーム情報を取得する（図 2）。
本件においては警報を各ビット単位で出力し、これ アラームが検出された場合、以下の方法でアラームによりきめ細かな警報の表現が出来るようになった。 通知を行う。アラーム通知の手段を図 5 に示す。
アラームレベルは各ビットについて、注意喚起、軽警報音
故障、重故障のいずれかが割り振られる。
AI, DI いずれについても、値の更新が遅れている警報音により監視員に対し注意喚起が行われる。
場合は時間判定によりアラームとなる。時間判定は、 警報音の種類は警報レベルの高さに応じて設定でき信号値と共にオンラインデータベースに書き込まれ る。
たタイムスタンプが、一定時間以上更新されないこ警報カラーとで判断される。
アラームと判定されれば、異常監視プロセスはオ
代表的な警報を示す第二階層画面上で、異常のンラインデータベースとアーカイブデータベースに あった機器群に対応した部品がアラームカラーに変アラーム情報を登録する。また警報発生後も周期毎 化し、異常の発生と、大まかな異常個所を知らせる。に信号値をチェックする。信号値が監視条件のしき 監視員は異常個所に応じて第三階層を開き、故障のい値から外れていなければアラームの回復、逆によ 詳細について確認する。その際、該当する画面を見り深刻なアラームレベルのしきい値を超えた場合は つけるための補助として、第三階層を開くボタンもアラームの遷移となり、その都度データベース上の カラーが変化するようになっている。階層的な表示
アラーム情報を更新する。
画面により、施設ユーティリティの多数の監視対象に対し最小限の画面表示で異常個所を特定できるよ4.3 画面表示プロセス
うになった。
画面表示プロセスの画面構成を図 3 に示す。第一
階層の小型のランチャーを基点とし、第一階層から 帳票第二階層、第二階層から第三階層を開くことが出来各階層画面の下部に帳票が用意されており、最新る。第二階層は空調・冷却系統と電気設備系統に分 の警報が文字情報で表示される。表示は警報レベル
かれ、それぞれ各建屋について 4 画面、合計 8 画面 （カラー）、信号名、信号の説明、日時と機器の所ある。第三階層は第二階層に従う形でより細かい区 属で表示される。全て表示させることも、画面内の分に分けられ、全 52 画面ある。各階層画面の監視 機器に絞り込むこともできる。帳票表示により、ど対象は、配管や電気的なつながりを基にしたライン の画面を開いていても常に全体の状況を把握するこでつながれ、機器同士の相関関係が分かるように とが出来るようになった。
なっている。第二階層の例を図 4 に示す。
各階層画面に加え、監視条件設定画面、監視状態これら各種アラーム通知により、監視員が迅速に、（サブグループ）設定画面、警報履歴画面がある。
適切な初期対応をとるための情報が提供される。またアラームの補助として、機器の表示の近くに機器4.3.1 アラーム通知と関連する AI 値の基準値（白色）と現在値（水画面表示プロセスは決められた周期でオンライン 色）を並べ表示させ（図 6）、トラブル発生時に画面上で具体的な数値を知ることが出来るようにした。
4.3.2 警報履歴
オンラインデータベースに保存されたアラーム情報は回復時に削除されるが、アーカイブデータベースではアラーム発生時と回復時にそれぞれ情報が追加され、履歴として残される。監視ソフトウェアの

図 6: アナログ値表示（基準値：白、現在値：水色）

図 5: アラーム通知方法- 720 -成し、平成 24 年 4 月から現在まで、改良と機能追加を行いつつ運用している。

謝辞
SACLA 施設ユーティリティ監視ソフトウェアは、スプリングエイトサービス株式会社の坂田様、白川様、中田様を始め、施設管理業務に関わる多くの方のご協力があって作製することが出来ました。ここに皆様への感謝の意を表します。

参考文献[1] T.Masuda et al., "FACILITY UTILITY CONTROLSYSTEM OF XFEL/SPRING-8", proc. of PASJ7, August
2010, Himeji, Japan[2] http://www.jema-net.or.jp/Japanese/standard/opcn/opcn05.
html[3] A.Yamashita et al., “The Alarm System for the SPring-8
Storage Ring”, proc. of ICALEPCS'97, Beijing, China,
1997 p.585.

図 7: トレンドグラフ
警報履歴画面では、期間や信号名で検索することにより、過去の警報を参照することが出来る。
4.3.3 監視条件と監視状態
監視条件設定画面により、AI 値、DI 値それぞれについて、しきい値と監視状態を設定する。設定されたしきい値はパラメータデータベースに保存され、アラーム判定に使用される。
監視状態には、監視、非監視、故障中の三状態があり、個別の機器に設定できるほか、機器群をまとめたサブグループに対して監視状態を設定することで、加速器の運転、停止、メンテナンス中などの状態に合わせ、機器の監視状態をまとめて切り替えることが出来る。
4.3.4 トレンドグラフ
警報発生後の AI 値の変化の推移を見るため、トレンドグラフ機能が追加された（図 7）。各 AI 信号に対して定めた数値の範囲を基準に、8 つの信号の変動の割合を同時にグラフ表示できる。グラフは設定した周期ごとに信号の現在値をプロットして描かれる。なお、信号値の過去の変化の履歴については、同じ監視データを用いた本件とは別の web システムにより提供されている。

5.

まとめ

データ収集系を加速器と共有し、階層的な構成の画面にアラームを表示させることで、監視対象の規模に対しコンパクトで効果的な施設ユーティリティ監視ソフトウェアを作成できた。
監視ソフトウェアは平成 23 年度に基本部分が完- 721 -