第20回日本加速器学会年会 - 2023年8月31日 -J-PARCリニアックLLRFシステムの高度化

高エネルギー加速器研究機構 二ツ川 健太
リニアック LLRFメンバー 高エネルギー加速器研究機構 Ersin Cicek, 方志高, 福井佑治, 溝端仁志,
NAT 佐藤福克, 日本原子力研究開発機構 篠崎信一
1J-PARCリニアック
J-PARC (Japan Proton Accelerator Research Complex)

IS: H− Ion Source
RFQ: Radio Frequency Quadrupole Linac
DTL: Drift Tube Linac (3 cavity modules)
SDTL: Separate-type Drift Tube Linac (16 cavity stations)
ACS: Annual Coupled Structure Linac (21 cavity stations)

J-PARC LINAC ビーム条件

マクロパルス構造

繰返し：25 Hz

中間パルス構造

周波数：~1.23 MHz• 加速粒子:H- (negative hydrogen)• 運動エネルギー:
400 MeV• ピークビーム電流:
50 mA• 加速周波数:324 MHz / 972 MHz• パルス:
500 µs (ビーム), ~650 µs (RF)• 繰返し:
25 Hz (ADSを除く)→ 大電流ビームを加速するため空洞内電界へのビーム負荷は大きく,ビーム負荷補償システムの性能が空洞内電界の安定度へ大きく寄与する。
マクロパルス内で, ビームの有り無しが繰り返される。
言い換えると, ビーム負荷の有り無しが繰り返され, 空洞内電界が揺さぶられる。2

J-PARCリニアック LLRFシステムµTCA.4システム導入: 2021年
夏期シャットダウン @ MEBT1µTCA.4システム導入

デジタイザのみ更新

for MEBT1 B1-2, C1-2

@ RFQ, DTL1-3, SDTL01-16

デジタイザのみ更新
2020年5月 @ SDTL02

デジタイザのみ更新
2020年1月 @ SDTL12µTCA.4システム導入µTCA.4システム

PC + タッチパネル機能付きディスプレイ

NIM電源

デジタイザ更新

旧システム (cPCI)

cPCIアナログモジュール

デジタイザボックス

チョッパコントローラ

2021年の夏期シャットダウンで, 324-MHz LLRFシステムのデジタル系を更新を完了した。この新規導入したデジタル系を使用して, ビーム負荷補償システムを開発した。

2021年夏期シャットダウン@ RFQ, DTL1-2

2020年夏期シャットダウン@ DTL2, SDTL01-16

3デジタイザボックス/MTCA.4の導入とその影響

制御の中心

cPCIのDFB・DFFを使用する既存のシステムでは, 制御の起点は, PLCであり, 全ての系統の信号はPLCを経由していた。

対応力を確保するために, 基本的には自営での開発

機能移行：• DFB・DFF用のEPICS IOC• 自動調整, 各機器に制御がまたがるシーケンス
J-PARCリニアックLLRFシステムの開発ツール• 電源のオフ/オンでの設定値の保持
ホストプログラム： RedHat8.0 gccコンパイラ Ver3.2• タッチパネルの機能を他で代用することが必要
DSP： TI社 Code Composer Studio Ver2.1→ ローカルの設定・モニタ： PC + タッチパネル付きディスプレイ
FPGA： Xilinx社 ISE Ver6.2i
表示アプリ： python2.4, wxPython2.6→ ILK発報履歴： 別途システム開発→ 開発環境を整備することが既に困難な状況→ トレンド監視： local archiver + css

cPCIシステムの老朽化のため, 維持は困難→ 持論：デジタルは20年も維持させるものではない!!!
J-PARCリニアックDFB/DFFのハードウエア
RF&CLKボード：
一部のICが廃版
FPGAボード：
廃版
DSPボード：廃版→ 予備品を大量に購入して, 現状を維持

デジタイザ/MTCAのDFB・DFFを使用するシステムでは, 配列の設定・モニタなど, PLCを起点とすることは困難であった。

4

PCとタッチパネル機能付きディスプレイ 1/2
Pro-face製のタッチパネルは, PLCは制御できても, デジタイザの制御は不可→ Pro-faceのタッチパネルの代わりにPC (TP-PC)を設置• remote/localはEPICSのASG• ローカルの設定・モニタ： PC + タッチパネル(TP)機能付きディスプレイ
メイン： cssベースでの開発
当初は, javaベースで開発してほぼ完成まで至ったが, ディスプレイの解像度が異なるとwidgetの配置が崩れて絶望した。
→ cssベースで再作成

トレンド： cssのdata browser活用

無線のマウスとキーボードも用意

TP機能付きディスプレイ

チューナの手動制御には, javaでの開発の画面が残る。

現在のJ-PARCのJAEA側のアーカイバは, ユーザからは自由に使い難い。
自営で, トレンドを表示するプログラムを作成するか, ローカルアーカイバを設けてdata browserを活用するかで検討→ 後者を選択 (ローカルアーカイバ： channel archiver → archiver appliance)→ この組み合わせは閲覧が便利なので, 監視頻度が高いレコードは,ローカルアーカイバでデータ収集

インターロック発報履歴： MySQLデータベース + python

PLCのDレジスタをリング
メモリのように用いている→ 高速ポーリングの必要がない

テキストで保存するか, データベースを使用するかで検討→ 後者を選択H2データベース + javaの組合せで開発したが, H2データベースの普及率？
→ MySQLデータベース + python

自動コンディショニング機能： javaで開発

PLCラダーからjavaプログラムに移行されたことは, インターロックと完全分離と, 間違いのない停止が可能となり, 安全性の向上につながった…はず。

5

PCとタッチパネル機能付きディスプレイ 2/2• PC状態(watch dogs)• KLY/DMY
Pro-face製のタッチパネルは, PLCは制御できても, デジタイザの制御は不可• ラックファンの状態• FB/FF ON/OFF→ Pro-faceのタッチパネルの代わりにPC(TP-PC)を設置• FBの補正値• 自動チューナ制御 ON/OFF• remote/localはEPICSのASG• 離調度• 自動復帰 ON/OFF• 波形保存• remote/local• ローカルの設定・モニタ： PC + タッチパネル(TP)機能付きディスプレイ
• 位相ドリフト補正• Auto-Start ON• バックグラウンド ジョブ(screen コマンド)• 出力変調 ON/OFF
下記の機能は, LLRF PLCラダーが担っていたが, screenバックグラウンドジョブとして実行• Auto-Conditioning ON/OFF• 自動波形監視 OK or Not
 自動RF立上げシーケンス• Stable OK or Not
 自動チューナ制御のシーケンス• 使用中のFF Table番号
 FF_BEAMのオン/オフ
更に, 上記とインターロック発報履歴のプログラムには, ウォッチドッグス機能を組込み, 居室から動作監視(実績上, プログラムはデバック時以外に停止したことはないが, しばしばPCはフリーズする。)

居室の監視画面6

サーバ/居室PCのバックグラウンド ジョブ
サーバPCのバックグラウンド ジョブ (screen)

オシロスコープ/VVM
光スイッチ制御
光遅延器制御 EPICSのsoft-IOC
 高周波基準信号分配システムのデータ収集
 位相ドリフト補正
 ビーム情報の取得 → インターロック統括監視システム用 (後述)

居室PCのバックグラウンド ジョブ (screen) RFダウン時のオシロスコープ波形の取得 → インターロック統括監視システム用
 ウォッチドックス： PCフリーズ, および他のバックグラウンドジョブの動作状態の監視

位相ドリフト補正： 位相差

位相ドリフト補正の効果： リニアック出射ビームの運動量

2月の運動量補正： 2回だけ7サーバ/居室PCの定時動作プログラム
サーバPCの定時動作プログラム (cron) RF波形の確認： 1回/時間→ 安定度が悪いと, 波形を保存して, 居室の監視ディスプレイに表示
 RF波形の保存： 3回/日
→ 波形を自動保存 (波形の安定度に関わらず)
 cPCIのインターロック情報をMySQLデータベースに保存： 2回/時間

居室PCの定時動作プログラム (cron) LLRF PLC シーケンスCPUの時刻合せ： 1回/日
 VSWRメータのパラメータの確認/記録： 1回/時間→ 変更に気が付かなかったことがあり, 導入 インターロック統括システムのアーカイブ： 1回/日8

GUI画面：監視・モニタ
古い画面：
新しい画面：

medm, java (制御Gr., 自作)
css (自作) → 制御LAN上のPCにcssがインストールされているとは限らない• ステーション毎に表示する画面： 各ステーションで5枚以上→ 全てのステーションで, 一斉にパラメータ変更するときに, 変更洩れなどが発生• RFの機能毎に表示する画面： ~30枚
• その他： ~5枚 (ビーム条件, 位相ドリフト補正, …)• トレンド表示(ローカルアーカイバ)
50台近いステーションを確認すると, どこまで確認したのか分からなくなる。

ゲシュタルト崩壊

ステーション毎に表示する画面

RF機能毎に表示する画面の例： FBパラメータ

9

GUI画面：パラメータ調整
pythonでパラメータの自動調整を実施：
調整用のデータ測定時の表示はなし： 同時に複数ステーションで測定を実施するため→ 必要に応じて, cssの画面で確認→ 測定結果を確認して, 問題がなければ設定に反映

10

GUI画面：その他• メンテナンスからの立上げ： チェックリスト & 操作画面を作成→ 立上げ担当&責任者を決め, RF立上げを実施• メンテナンスでオフにした機能の復帰• 必要に応じてDFB&DFFシステムの微調整• 機器の動作状況の確認• 1週間のトレンドの確認• …
→ グループ内の全員がシステムに触れるように…半強制的…
• RF機器の交換： 予備品は完全互換ではない (より安全に： N.O. → N.C.)→ プログラムから誰でもPLCラダーを用意に変更可な状況

PLCの特定のIレジスタを変更することで変更可能
但し, 敢えてEPICSレコード化はしていない。

11インターロック統括システム 1/3• RFダウン波形の保存→ 空洞から反射データ有り
RFダウン波形のオシロスコープの画面を保存

一ヶ月に1000件弱のインターロック事象がある。

リニアックLLRF ILK発報回数
1400
1200
ILK発報数• インターロック発報履歴システムの拡張
デジタイザ更新時にTP-PCに置いたインターロック発報履歴システムが非常に有用→ デジタイザを更新していないステーションにも応用
アーカイバへの自動保存は30分に1回, 任意のタイミングでの手動保存も可

1000

1297

800
600
400651806854653646

2000• RFダウン情報の保存→ 前のパルス情報有り
更新されたデジタル系の高速モニタ(波形とJ-PARCのイベントタグの取得)→ 高速モニタの実装：
 64pulses/bank, 16banks, 16383smps/pulse, 64bytes/smpのリングメモリで構成された高速モニタを実装
 ADC1~8,DAC,VS,IIR,REF,PI,FFの各IQ→FB中の計算過程も含めて,メモリに書き込む
 パルスデータのeventfooterには, J-PARCイベントタグ情報を付加
event footer
0-3:
4-7:
8-11:
12-15:
16-19:
20-63:

イベントタグ識別情報(0xaa55aa55)
TYPEデータ
TYPEデータ
S_EVENT情報
S_COUNT情報
イベントタグ識別情報
TRIG_COUNT情報
0固定

S_COUNT情報
TRIG COUNT情報12

インターロック統括システム 2/3
インターロック事象の半自動解析でデータベースに保存
自動: 数秒毎“DIGI”データベース

デジタイザ/MTCAステーション:
ILK発報事象 → MySQLサーバに保存
cPCIステーション:
ILK発報事象 → MySQLサーバに保存
正常波形と同時に表示

自動: 1回/日“CPCI”データベース

beam ON/OFF

pngファイルは/jkdata/jkpublic上に置かれてJLAN上から確認できると共に, 制御
LAN上にrootのcanvasも保存して後々に詳細確認も可能
ダウンタイミングのzoom

正常波形との差分

MySQL

発報タイミング, QR成功 or 失敗
時定数→ A or B
推定ビーム幅(MLF or MR)
推定発報原因RFダウン波形のpngファイル名
目視の確認が必要かどうか

ビーム運転時 or それ以外
ビーム停止時刻, 復旧時刻

解析

ILK内容
ILK発報時刻
復旧時刻
解析データを“MPS”データベースに保存
RFダウン波形のpngファイル名
前のパルスが正常かの判断→目視の確認が必要かどうか
J-PARCイベントタグ (ビーム行先)

自動：RFダウン毎

RFダウン波形の取得
目視確認が必要そうな事象は黄色表示RFダウン情報の取得
13インターロック統括システム 3/3
自動化できない箇所： “道連れ”MPS事象(Zlogから引き抜き), プログラムが目視を推奨したイベント“道連れ”MPS事象→ mysql-workbenchで用意にデータの編集が可能
自動入力を確立すると管理が容易になる。

将来は, 大きな故障前の予兆検出が可能か？ (1例)

2022年2月に, RF Gr.から空洞Gr.にDTL3上流カプラ近辺(5事象)とSDTL11Bカプラ近辺で不可思議なインターロック発報現象を報告
真空悪化が伴っていなかったので2022年夏期シャットダウン時立体回路の可能性もあったため
SDTL11Bカプラの交換を実施 (空洞Gr.)DTL3の立体回路の健全性の確認 (RF Gr.)
2022年の夏期シャットダウン中に2023年2~3月にDTL3で放電が頻発
交換できていれば, 避けられた→ 急遽, DTL3のカプラの交換を実施可能性が大きい。

14

Mattermostの導入“Slack”のような“Mattermost”のローカルサーバを制御LAN上に設置→ pythonプログラム上から, 記録が可能 → プログラムからの自動書記を組込み
下記のチャンネルを用意して, 重要項目は自動で記録ができるシステムを実現• data-acquisition：データ収集のログ ← 基本見る必要なし, 気になったら見る• parameter-set：パラメータ設定のログ ← 基本見る必要なし, 気になったら見る• program-error：プログラムのエラー ← 基本的に見る, デバックに役立てる• status-log：状態の記録 ← 絶対見る, 基本的には悪いときに書く• temporary：テンポラリ ← 見る, テンポラリの状態に設定したときに書く, ex. HWの停止とか15

まとめ• J-PARCリニアックのLLRFでは, 人手不足&予算不足をシステムの高度化で補うように努力をしている。今回は, 現状を報告したが, 機能の追加のための開発は常日頃から行っている。
• 今回の発表にはありませんでしたが, 同時に不必要になった機器の取外しや機能の削除も実施して, システムを単純化させる努力も行っている。
• 自営でのシステムの導入や改良を進めていることもあり, 開発スピードは決して早くはない。しかし, その分, 対応力&適応能力は高く, 後発開発が活きるLLRFでは重要だと考えている。

16