Proceedings of the 20th Annual Meeting of Particle Accelerator Society of Japan
August 29 - September 1, 2023, Funabashi

PASJ2023 THOA7J-PARC MR 制御システムの 15 年間の運用と今後の展望
15 YEARS OF THE J-PARC MAIN RING CONTROL SYSTEM OPERATION AND ITS
FUTURE PROSPECTS山田秀衛 ∗,A)
Shuei Yamada ∗,A)
A)
High Energy Accelerator Research Organization (KEK) / J-PARC Center

Abstract
The accelerator control system of the J-PARC MR started operation in 2008. Most of the components of the control computers,such as servers, disks, operation terminals, front-end computers and software, which were introduced during the construction
phase, have went through one or two generational changes in the last 15 years. Alongside, the policies for the operation ofcontrol computers has changed. This paper reviews the renewal of those components and discusses the philosophy behind theconfiguration and operational policy. It is also discussed the approach to matters that did not exist at the beginning of the project,such as virtualization or cyber security.

1.

はじめに

J-PARC (Japan Proton Accelerator Research Complex) は高エネルギー加速器研究機構 (KEK) と日本原子力開発機構 (JAEA) が共同で計画・開発・運営する大強度陽子加速器施設で、2001 年に建設を開始し、2007 年に運用を開始した [1]。J-PARC 加速器の制御システムは、二つの異なるマシンサイクルのためのそれぞれの加速器制御システムから構成されている。25 Hz のサイクルで運転される LINAC (LI) と Rapid Cycle Synchrotron (RCS)の加速器制御システムは JAEA が、運転モードによって1.36 s または 4.20 s サイクルの Main Ring (MR) は KEKが担当している。これら 2 つの制御システムは、タイミングシステム、ネットワーク、ストレージ、EPICS [2]という共通の基盤の上に構築されており、綿密に連携することで全体をひとつの加速器として制御している。
本論文では、2008 年に運用を開始した MR の加速器制御システムの 15 年間の運用の歴史と今後の展望について議論する。広義の加速器制御システムにはタイミングシステム [3, 4]・人的保護システム [5]・機器保護システム [6, 7] も含まれるが参考文献に挙げるに留め、EPICS を用いたネットワーク分散型制御システムのコンポーネント (ネットワーク・ストレージ・計算機・ソフトウェア環境) について注力する。

2.

ネットワークFigure 1: Logical Topology of the J-PARC Accelerator Network.

ト保守サービスにより、障害の原因究明・対策や故障した部品の交換が速やかに行われる。
ネットワークは VLAN で各施設 (LI・RCS・MR・MLF・HD・NU) と CCR の 7 つのセグメントに分割している。
ある施設での通信障害等がほかの施設に及ぼす影響を最小限に止めるようにしてある。
加速器制御ネットワーク全体では約 250 台のエッジスイッチを使用している。LI と RCS はネットワーク末端までエッジスイッチで構成されている。MR では中間的なスイッチにエッジスイッチ 12 台を使用しているが、末端には SOHO 向けのスイッチングハブを使用し、導入と保守のコストを削減している。

2.1 ネットワークの構成
J-PARC 加速器制御 LAN の論理的な構成を Fig. 1 に示す。ネットワークの中核となるコアスイッチは中央
制御棟 (CCR) に設置され、LI・RCS・MLF 実験施設・
MR 第 3 電源棟 (D3) にぞれぞれ設置されたエッジスイッチまで光ファイバで配線されている。D3 からはさらに、MR の二つの電源棟 (D1・D2) と二つの実験施設(NU・HD) のエッジスイッチまで配線されている [8]。
コアスイッチとエッジスイッチは冗長構成で、障害発生時には主系から副系に切り替わる。またオンサイ∗ shuei@post.kek.jp

2.2

ネットワークの歴史

J-PARC 加速器制御のネットワーク機器はこれまでExtreme 社の製品を導入しており、7–8 年毎に全てのコアスイッチとエッジスイッチを更新している。2005 年に LI で制御ネットワークの運用を開始し、2007 年には MR にまでネットワークが延伸された。バックボーンの帯域は 10 Gbps、建屋間は 1 Gbps であった。2011年から 2015 年にかけて機種更新し、バックボーンは40 Gbps、建屋間は 10 Gbps となった。
2019 年から 2 回目の機種更新が行われている。2024
年に更新が終了し、バックボーンは 100 Gbps、建屋間は 10 Gbps となる予定である。

- 172 -

Proceedings of the 20th Annual Meeting of Particle Accelerator Society of Japan
August 29 - September 1, 2023, Funabashi

PASJ2023 THOA7

ネットワーク・ディスクがいずれも冗長化されており、障害発生時・メンテナンス時にも運転を継続できること、必要に応じてシェルフ・ディスクを追加し容量を拡張できることから NetApp 社製の製品またはその OEM品を選択した。オンサイト保守契約を結んでおり、障害の原因究明・対策や故障した部品の交換が速やかに行われる。
3.2

Figure 2: Relationship between accelerator control network,
J-PARC office network, and the Internet.

2.3 セキュリティ
J-PARC の加速器制御ネットワーク、オフィスネットワーク、インターネットの関係を Fig. 2 に示す。制御ネットワークはオフィスネットワークからは独立したプライベートネットワークで、マルウェアやウイルスを持ち込ませない様々なセキュリティ対策を講じている。
制御ネットワークとオフィスネットワークは単にファイアウォールで分離するだけでなく、直接の通信を禁じている。これらの間には DMZ が設けられており、制御ネットワーク–DMZ 間の通信と DMZ–オフィスネットワーク間の通信だけが許可されている。
制御ネットワークからオフィスネットワークや外部のネットワークへの通信は、DMZ に設置された HTTPプロキシサーバまたは SSH サーバを経由する通信のみに制限している。HTTP に関しては、ホワイトリストに登録されたサイトへのアクセスのみを許可している。
一方オフィスネットワークから加速器制御ネットワークへの通信は、当初は DMZ に設置された HTTPサーバへの HTTP と SSH サーバへの SSH のみに制限していた。2018 年に EPICS の通信プロトコルである
Channel Access (CA) をネットワーク間で転送するゲー
トウェイを DMZ に追加し、オフィスネットワークからの読み取り専用アクセスを可能にした [9]。SSH と CA
は、オフィスネットワーク側の IP アドレスによるアクセス制限を行っている。
加速器制御ネットワーク内の計算機には、危険度に応じてアンチウイルスソフトを導入している。また、特定多数のユーザがつかう制御ネットワーク内の端末計算機は、USB ストレージを使用できないよう設定してある。サポートが切れた古いバージョンの OS も原則として使用禁止である。

3.

ストレージ

3.1 ストレージへの要件
長期間の加速器の運転と高い可用性を実現するためには、ストレージシステムの信頼性と拡張性が重要である。MR では、ファイルサーバに特化した OS を採用したアプライアンス製品であること、コントローラ・ストレージシステムへの歴史

2008 年にディスク容量 9 TB の IBM 社製 N3600 を導入し、2012 年には容量を 28 TB へと拡張した。2013年に 48 TB の NetApp 社製 FAS2240 へと最初の機種交換を行い、2014 年には 84 TB へと拡張された。2022
年に 2 度目の機種更新を行い、192 TB の Lenovo 社製
DM3000H になった。
いずれも運用を開始して 5 年程度経過するとディスクが故障して交換する必要が生じる程度で、特筆すべきトラブルは経験していない。2023 年現在、約 500 台のクライアントに対する NFS サーバとして稼働中である。
3.3

補助的ストレージとしての Linux サーバの導入

MR の加速器制御システムは、加速器運転用プログ
ラム・運転データ・各ユーザのホームディレクトリなどのすべてをストレージシステムに置き、NFS で共有する設計であった。しかしながら、信頼性・I/O 性能・拡張性よりもディスク容量と低価格を重視した汎用 OS(Linux) を採用したラックマウント型のファイルサーバを 2012 年から導入し、特定の用途に供している。
加速器を運転するに伴ってデータは増える一方(∼10 TB/yr) であるが、古いデータはそれほど参照されることがない。運転から 1 年以上経過した shot-byshot の波形データはストレージシステムからファイルサーバに移動している。2012 年にディスク容量 24 TBの IBM x3630M3 を 2 台導入し、2016 年には 84 TB のx3630M4、2022 年には 216 TB の Lenovo SR550 へと機種更新を経ている。
EPICS アーカイバで記録している時系列データも、当初はエンジンをサーバ計算機で実行し、ストレージシステムに記録していた。2016 年に機種更新で余剰となった x3630M3 で次期アーカイバの評価を開始した。
2017 年に 112 TB の Lenovo x3650M5 を導入し、アーカイバの CPU 兼ストレージとして運用を開始した [10]。

4.

サーバ計算機

4.1

サーバ計算機のハードウェア

当初 MR 加速器の制御システムでは、運転用プログラムをサーバ計算機で実行し、X 端末的に運用される端末計算機で表示するアーキテクチャを採用した [11]。
その後 2014 年に端末計算機を更新した [12] のを機に、運転用プログラムも端末計算騎で実行するようになった。本節と 4.2 節でサーバ計算機のハードウェアと運用形態の変遷について論じ、5 節で端末計算機について議論する。
サーバ計算機の運用方針は、(1) サーバの能力には余裕を持たせておき (2) 故障したらほかのサーバに負荷- 173 -Proceedings of the 20th Annual Meeting of Particle Accelerator Society of Japan
August 29 - September 1, 2023, Funabashi

PASJ2023 THOA7を開始したが、評価を終える前の 2020 年 7 月に 1 台の筐体が故障した。筐体の修理は断念した。
利用可能な Blade がこれまでの半分の 11 枚となったため、急遽 8 台の SR530 を手配した。SR530 が利用可能になるまで、利用可能な 11 台の blade に加えて試験導入した 2 台の SR530、IOC 用の 4 台のファンレスサー
バ (6 節)、1 台の端末計算機 (5 節) でサーバ計算機システムを仮復旧し、半年のあいだ加速器の運転を継続した。
2021 年 7 月に全ての Blade 計算機を廃止して 10 台のSR530 に移行した。その後 2022 年 3 月に 2 台を追加して現在に至る。Table 1 にサーバ計算機の典型的な仕様を示す。
Blade 型サーバのメリットは機種更新が低コストな点で、安定に運転していた 12 年間の間に機種更新を重ねHS20 から HS23e までの 4 世代 7 機種を運用した。その一方で筐体が大きくスペースを要し、電源容量が利用可能な Blade の枚数を制限してしまうといったデメリットも明らかになった。筐体の寿命が blade システム全体の寿命を決めるという、想定されていたシナリオも回避できなかった。

(a) An enclosure populated with 14 blades.

4.2

Blade 型サーバの運用を開始した当初は、個々の bladeに運転プログラム実行用・DHCP サーバ・DNS サーバといった個別の機能を割り当てていた [11]。2011 年にScientific Linux (SL) 4 上の XEN 仮想マシンで動作するIOC (VIOC) を加速器の運転に投入した。2012 年に SL6上の KVM 仮想マシンに移行すると同時に、DHCP・DNS といった複数の小規模なサーバを仮想マシンに移行し、1 台の blade に集約した [13]。
2014 年の端末計算機の機種更新 (5 節) で運転プログ
ラム実行用サーバの負荷が減り、仮想マシンホストへの転用が進んでいる。2023 年現在、約 100 台の仮想マ
シンを 5 台のサーバで運用している。
仮想マシンを導入することで計算機資源の有効活用が可能となり、ライブマイグレーションによる耐障害性も向上した。また、IOC の負荷分散や試験用 IOC の立ち上げ、古いバージョンの OS 用の開発環境の維持も容易になった。
Docker・LXC のようなコンテナ技術も試験・評価しているが、加速器の運転に投入するには至っていない。

(b) A single blade server.

Figure 3: Appearance of blade server system.

Table 1: Typical Specifications of Servers
ModelCPU

disk spaceHS23e

Xeon E5-247048 GB

SR530

Xeon Gols 5215

96 GB

運用形態の変化と仮想化を振り分け、加速器の運転を継続する (3) サーバの負荷が増えたら中期的にサーバを増設する (4) 会社によるオンサイト保守を行う、というものである。
2005 年に 1 台の IBM 社製の Blade Center E 筐体と5 枚の HS20 で運用を開始した (Fig. 3)。2007 年には 2台めの筐体を導入し、それ以降随時 blade を増設した。
2010 年には筐体 2 台にフル実装し計 28 枚の体制となった。2014 年に当時の最新機種 HS23e を投入したところ筐体の電源容量が不足することが判明した。blade を 22枚に減らすことを余儀なくされたが、全体としての計算機能力は増加させた。
2018 年から 2019 年にかけて筐体のメーカー保守が終了した。Blade 型からラックマウント型サーバへの移行を検討するため、2019 年に試験的に 1U のラックマ
ウントサーバ (Lenovo 社製 SR530) を 2 台導入して評価

4.3

特定用途向けサーバ計算機

2010 年からは特定用途向けのサーバも導入している。加速器のシミュレーションは、加速器運転用に選定したサーバの仕様とはそぐわない。シミュレーションの特性に合わせた CPU コア数・メモリ容量・GPGPU 等を選定した計算機を導入している。2.3 節で述べたゲー
トウェイや 3.3 節に述べたアーカイバ用サーバも、この範疇に含めてよかろう。

5.

端末計算機

2006–2007 年に端末計算機として 2 または 4 ディスプレイ構成の HP 社製の Thin Client 端末を約 20 台導入した。多数の端末の運用と管理を簡便にするため、ネットワークブートで SL4 を起動し、X 端末的に利- 174 -Proceedings of the 20th Annual Meeting of Particle Accelerator Society of Japan
August 29 - September 1, 2023, Funabashi

PASJ2023 THOA77.

OS と EPICS

7.1

ソフトウェアの考え方

計算機の運用上の観点からは、サーバ・端末・IOC は同じバージョンの OS・EPICS を使い、かつ可能な限り長く使い続けるのが望ましい。一方、セキュリティ上の観点からは、頻繁にソフトウェアを更新したい。
MR 制御システムではこの相反する要望の妥協点として、いちど導入した OS はサポートが終了するまでメジャーバージョンを変えずに使い続けているが、可能な限りこまめにパッチをあてて更新している。実際には夏季計画停電・年末年始・年度末等の加速器の長期メンテナンスの際に OS にパッチをあて、必要なら再起動する。ただし、サーバを再起動するのは原則として
Figure 4: Intel NUC (left) and Thin-client (right).
夏季計画停電の際だけである。
EPICS base は原則として導入時点での最新の安定板を選択し、それを使い続けるが、深刻な問題がある場合用した [14]。サーバと IOC の OS が SL6 に更新されたには EPICS base のパッチレベルを上げることもある。のを機に、2014 年に Intel 社製の NUC へと機種更新しEPICS のサポートモジュール、特に内製のものは必要た [12]。高速な CPU と大容量メモリ容量を搭載しておに応じて更新している。いずれも予備の計算機・制御
り、これまでサーバで実行していた運転用プログラム対象機器で試験・開発し、その後運転環境に投入してを端末計算機で実行することができるようになった。
いる。
Thin Client と NUC の外観を Fig. 4 に、典型的な仕様をTable 2 に示す。
7.2 MR の加速器制御ソフトの変遷
NUC はメーカー保守のない低価格な小型 PC だが、2008 に MR の制御システムのソフトウェアとして意外と堅牢である。2014–2015 年に導入した 30 台中 20
SL4 と EPICS R3.14.7 を採用し、EDM・MEMDM・Strip台が 2023 年でも稼働中である。また新機種が毎年登場
Tool といった EPICS で標準的な GUI プログラムを利用しより高速な CPU と大容量なメモリが利用可能になるしていた。2012 年に SL4 のサポートが終了したため、が、ソフトウェアの互換性と管理上の観点からは大き2012 年にサーバ計算機を、2013 年には IOC を SL6 とな差異はない。随時新機種を試験して予備機とし、故EPICS R3.14.12.3 に移行した [17]。制御端末である Thin
障時の交換・端末の増設に備えている。2023 年現在、2Client は SL6 で動作させるのが困難であったため 2014
ディスプレイ構成で約 45 台を運用中である。
年に NUC へと機種更新した [12]。これによりサーバ・制御端末・IOC のソフトウェアが SL6 と EPICS R3.14.12.3
Table 2: Typical Specifications of Terminalsに統一され、制御端末上でよりモダンな GUI である
Control System Studio の利用も可能となった [18]。
ModelCPU
memorydisk
2019–2020 年には CentOS7 と EPICS R3.15.5 に移行
HP t5720
Geode NX1500 512 MB none
し、2020年に予定されていた SL6 のサポート終了に備Intel NUC8i5BEH
Core i5-8259U
32 GB
SSD
えた。可能であれば CentOS8 に移行したいところであったが、2019 年に購入した NUC を早急に加速器の運転に投入する必要が生じ、CentOS8 のリリースを待たずに
6 . フロントエンド計算機 (IOC)CentOS7 への移行を進めた。2020 年には EPICS R3.15.5
2007 年に IOC として VME SBC を選択した [15]。2008 で CPU が暴走するケースが判明したため、R3.15.8 へ
年に Linuc 対応 PLC CPU(横河電機製 F3RP61) が、2010 と更新した。CentOS8 のサポートが 2022 年に前倒しさ
年には VIOC が導入された。VME SBC は堅牢で良い選 れたため、結果的に CentOS7 の採用は正しい選択だっ択であったが、制御対象機器の多くはネットワーク接 たといえる。
CentOS7 のサポートは 2024 年に終了する予定であ続の PLC やオシロスコープといった機器であり、7.3 節で述べる例外を除くと VME 筐体を単なる電源として る。2023 年から Alma Linux 9 と EPICS R7.0.7 への移行利用していた。MR の高度化に伴って IOC が増えてく を開始しており、2024 年に移行を完了する予定である。
ると、少数の VME SBC であっても VME クレートが必
7.3 一部の例外
要でスペースが不足すること、クレート内の VME SBC
多くの機器はネットワーク接続で制御しているが、が電源を共有することが運用上の足枷となってきた。
2014 年に小型ファンレスサーバ (PiNON 製サバ太郎 ここで計算機のバスに直結した機器を制御しているたType-P) を導入し [16]、2023 年に VME SBC からサバ太 めに OS を更新できない機器についてまとめておく。
MR のタイミング受信モジュールは内製の VME ボー郎への移行が完了する予定である。MR の運転用 IOCの種別と変遷を Table 3 にまとめる。典型的な IOC の外 ド で あ る。 そ の 制 御 に 用 い る IOC は SL4 と EPICS
R3.14.7 で動作する VME SBC (GE 社製 VME-7700RC)
観を Fig. 5 に、仕様を Table 4 に示す。

- 175 -Proceedings of the 20th Annual Meeting of Particle Accelerator Society of Japan
August 29 - September 1, 2023, Funabashi

PASJ2023 THOA7

Table 3: Evolution of Types and Numbers of IOCs
2007

2008

2011

2013

2014

2015

2016

2021

2023

VME SBC

∼80

∼80

∼90

∼80

∼80

∼90

∼90

55

37

microIOC

3F3RP6133333330∼10∼30∼40

∼45

∼45

∼4569

69a few

∼30

∼30

∼30

∼303944a few

11∼305080

VIOC
Saba-taro(a) VME SBCs(b) Yokogawa F3RP61.

(c) PiNON Saba-Taro Type-P.

Figure 5: Three form-factors of front-end computers.
Table 4: Typical Specifications of IOCs
CPUmemory

disk

Sanritz SVA041 (VME SBC)

ModelCeleron-M 600 MHz

512 MB

diskless

Yokogawa F3RP61

ppc603e 600 MHz

128 MB

CF cardCeleron J1900

8 GB

SSD

PiNON Saba-taro Type-Pである。より新しい OS に移行するためには VME SBCの機種更新が必要であるが、VME バスにアクセスするためのハードウェアが変わるため、デバイスドライバやアプリケーションを大幅に書き換える必要がある。
J-PARC 加速器のタイミングシステムを次世代ものへ更新するのに伴って PLC モジュール型の受信機に移行することを選択した [3, 4]。25 台ある VME 型のタイミン
グ受信 IOC のうち、23 台は PLC 型に移行する予定である。残りの 2 台も長期的には PLC 型への移行を検討している。
MR の ビ ー ム ロ ス モ ニ タ に 用 い る ADC も 内 製 のVME ボードを利用している。制御用の IOC は SL6 とEPICS R3.14.12 を採用した VME SBC (GE 社製 V7865)である。全 12 台をサンリツオートメイション社製の SVA061 に機種更新し、ソフトウェアも CentOS7 とEPICS R3.15.8 に移行する予定である。
F3RP61 は横河電機社製の PLC モジュール用の Linux対応 CPU モジュールで、CPU には Power PC が、OSには ELDK ベースの組み込み Linux が採用されている。CPU モジュールを EPICS IOC として動作させることが可能で、IOC からはバックプレーンに実装されたPLC モジュールを読み書き可能である [19]。後継機種の

F3RP71 では CPU が ARM に、OS が Yocto ベースのものに変わっている。MR の制御システムでは約 70 台のF3RP61 を運用しており、2022 年から試験的に F3RP71への移行を開始した。

8.

まとめ

本論文では、2008 年に運用を開始した J-PARC MR の加速器制御システムを概説した。制御システムの各コンポーネントはこの 15 年間で 1–2 回の世代交代を経ており、その間に変化した運用形態とその背景を論じた。
予備機で新しいソフトウェアとハードウェアを試験し、運転用の環境やサーバ計算機に展開するアプロー
チは今のところうまく機能している。制御システムのコンポーネントの寿命は長いものでも 10 年、短いものは 2–3 年で、年々短くなる傾向にある。制御システムのソフトウェアの基盤として今後も Linux と EPICS を使い続けることが予想されるが、ソフトウェアとハードウェアは相互に依存しており、足並みを揃えて更新する必要がある。制御システムを全体として維持していくには、継続的な R&D が必要不可欠である。

- 176 -

Proceedings of the 20th Annual Meeting of Particle Accelerator Society of Japan
August 29 - September 1, 2023, Funabashi

PASJ2023 THOA7

参考文献[1] N. Kamikubota et al., “J-PARC Control toward Future Reliable Operation”, Proc. ICALEPCS 2011, pp. 378-381,
MOPMS026.
[2] EPICS - Experimental Physics and Industrial Control System, https://epics-controls.org/[3] N. Kamikubota et al., “Ten-year oeration and experiancedtroubles of J-PARC MR timing”, Proc. PASJ2019, THOI07.
[4] F. Tamura et al., “Next generation timing system for JPARC”, Proc. PASJ2019 pp. 149-152, THOI08.
[5] N. Kikuzawa et al., “Present Status of Personnel Protection System at J-PARC”, Proc. PASJ2019pp. 877-880,
FRPH006.
[6] T. Kimura et al., “Performance Evaluation of MR-MPS andDevelopment Plan of New MR-MPS for J-PARC”, Proc.
PASJ2017, pp. 1148-1150, WEP101.
[7] H. Takahashi et al., “Update of MPS Modules for JPARC LINAC and RCS (2)”, Proc. PASJ2021, pp. 914-917,
THP038.
[8] N. Kamikubota et al., “Network System Operation for JPARC Accelarators”, Proc. ICALEPCS 2017, pp. 14701473. doi:10.18429/JACoW-ICALEPCS2017-THPHA047[9] S. Yamada, “Real-time and Detailed Provision of J-PARC
Accelerator Operation Information from the Accelerator
Control LAN to the Office LAN”, Proc. PCaPAC 2018, pp.
167-169. doi:10.18429/JACoW-PCaPAC2018-THP04[10] S. Yamada et al., “Deploynment of archiver applianceat J-PARC main ring”, Proc. PASJ2017, pp. 1144-1147,

WEP100.
[11] N. Kamikubota et al., “Computer Environment for J-PARCMR Operation”, Proc. 7th PASJ (2010), pp. 690-692,
WEPS116.
[12] S. Yamada, “Renovation of PC-based Console System for
J-PARC Main Ring”, Proc. PCaPAC 2014, pp. 81-83,
WPO021.
[13] N. Kamikubota et al., “Experience of Virtual Machines in JPARC MR Control”, Proc. ICALEPCS 2013, pp. 417-419,
MOPPC131.
[14] S. Yoshida et al., “Console System Using Thin Client for
the J-PARC Accelerators”, Proc. ICALEPCS 2007, pp. 383384, WPPA33.
[15] N. Kamikubota et al., “Operation Experience and Migrationof I/O Controllers for J-PARC Main Ring”, Proc. PCaPAC
2016, pp. 101-104, THPOPRPO09.
[16] S. Yamada, “Deployment of a Tiny Fan-Less Server as
IOC in J-PARC Main Ring”, Proc. PASJ2016, pp. 634-636,
MOP092.
[17] S. Yamada, “Upgrade of software toolkits for EPICS Input
Output Controllers in J-PARC Main Ring”, Proc. 10th PASJ
(2013), pp. 1106-1108, SUP080.
[18] S. Yamada et al., “Deploynment of Control System Studio at J-PARC Main Ring”, Proc. PASJ2015, pp. 767-769,
WEP103.
[19] J. Odagiri et al., “Development of Embedded EPICS on
F3RP61-2L”, Proc. 5th PASJ (2008), pp. 240-242, FO05.

- 177 -