KEK 電子入射器の制御システム
古川 和朗 、上窪田 紀彦y高エネルギー加速器研究機構 (KEK)

概要

はビーム運転で使用される応用プログラムについて、それぞれ扱う。また、第 7 節では制御グループが担当して大型加速器は寿命が長い上に 、運転開始後も極限まいるタイミングシステムについても解説する。最後に、で性能を高める必要があるために 、制御系にもさまざ
まな機能拡張が可能となるような柔軟性が求められる。

第 8 節で今後の展開について議論していくことにする。

また 、加速器モデルと現実の加速器を対比しながら運転できるような仕組みも必要となる。もちろん、加速器を長期間安定に運転するために、その信頼性・可用性も重要である。KEK の電子陽電子入射器では 、600m にわたって分散配置された装置約千台（ 信号数約一万点）
を総合的に監視・制御することで高品質なビームを生成

2

加速器の制御2.1

加速器の制御の歩み

し 、KEKB 、PF 、PF-AR それぞれに適したビームを入一般に加速器の制御は加速器の特性、つまり加速器射している。その制御系及びタイミング系の設計方針や内の機器の数やパルス運転か連続運転か、などによって実装、そして将来の方向性について解説する。

多少構成が異なるが 、大きくは変わらない。しかし 、その構成技術が、一般の加速器構成機器に比べて進歩の激しい計算機やネットワーク技術などに依存している部分が多く、また、それに伴って加速器制御に対する考え方

1も変わってきているため、過去に大きな変化を遂げてきはじめにた。全般的に言って、その重要度は増してきていると思われる。

制御システムは 、加速器を運転する際にはある意味主役を演じることになる。つまり、加速器内の各機器の2.1.1

最大性能を引き出しつつ、オペレータに的確な情報を提1980 年代

大型加速器では、CERN の SPS がミニコンピュータ

供し 、最終的に期待した性質を持ったビームを生成する仕事を受け持つ。

のネットワークと NODAL という加速器用のインタプリ

KEK の電子陽電子入射器は、KEKB リングへ 8 GeVの電子と 3.5 GeV の陽電子を、PF リング及び PF-AR リ

タ言語によって運転を行い、ひとつの時代を開いたと思われる。日本では、KEK の電子入射器の初期の制御シングへ 2.5 GeV または 3 GeV の電子をそれぞれ入射しステムが機器を制御する数百台のマイクロコンピュータている [1] 。リングにおける実験効率を向上させるためを独自の階層的なネットワークで接続し 、計算機遠隔制に、入射ビームにも高い安定度が要求され 、長期間にわ御を実現させた [4] 。その後 Fermilab の Tevatron が複合たる高安定なビーム加速を実現するためののさまざ ま

加速器を ACNET と呼ぶひとつのソフトウェアインター
フェース (API) で制御を可能にし 、また SLAC が SLC

な機構が導入されている [2, 3] 。

のための高速制御を可能にした [5] 。日本でも TRISTAN

この解説では、第 2 節で一般的な加速器の制御について、第 3 節で KEK 電子入射器の制御の概要について、 が NODAL とデータモジュールと呼ぶソフトウェアを組み合わせ、機器指向の制御を実現した。
それぞれ説明する。その後、KEK 電子入射器の制御シ
ステムの詳細を解説するが 、第 4 節では計算機、ネッ

それ まで 、遠隔多重制御を行うために導入されてきトワーク、フィールド コントローラを中心としたハード

た計算機が 、徐々に本質的に必要になってきた年代であウェアについて、第 5 節ではこの制御システムのためにる。例えば 、SLAC の SLC は制御システムがなければ開発された多階層制御ソフトウェアについて、第 6 節で運転できなかったであろう。このように、制御システム

 <kazuro.furukawa@kek.jp>
y <norihiko.kamikubota@kek.jp>の重要度が増してきたこともあり、1985 年からは Inter-natinal Conference on Accelerator and Large Experimental
1Physics Control Systems (ICALEPCS) という国際会議が技術を最大限利用しようとする動きも活発で、DESY の1

2 年毎に開催されている 。
2.1.2

HERA[13] では種々のサブシステムを多数の Windows
計算機で統合している。Linux の信頼性が高まるにつれ、

1990 年代利用するシステムも増えてきている。

その後、一般の計算機やネットワークの規格の統一

加速器のモデリングを現実の加速器の運転で直接対が進み、それらを活用した加速器制御も変化がはじまっ

比させながら利用する試みについてもさまざまな形で行た。一時期は Unix ワークステーションなどのウィンド

われている。しかし 、制御グループと、運転またはビー

ウシステム、TCP/IP と FDDI 、イーサネットなど の標

ム物理グループの間の垣根が高い場合もあり、実証試験

準ネットワーク、そして VME などのフロントエンド 計と日々の運転は別、という例も少なくない。そのなかで算機を組み合わせることを “標準モデル ” などと呼ぶよも有効に使われたと思われるのは LEP の運転コンソーうになった [6] 。このころ、KEK の電子入射器の初期のルシステムである。また、KEKB の SADscript/Tk は大制御システムの更新も行われ [7, 8, 9] 、あとで述べるよきな成功を収めており、入射器のためのものも含めてさうに、この標準モデルに近い形態になった。

まざ まな運転用ソフトウェアが利用されている [14] 。

それまでは、各加速器で独自の計算機やハード ウェア

KEK の電子入射器でもあとで述べるように、上に挙を開発することが多かったが、これらの標準的な制御シげた技術を適材適所に利用してシステムを構築し 、まステムの形態によって、制御システムの課題は、いかにた、改善し続けている。

大きな制御システムを管理運営していくか 、また 、い2.2

かに各加速器間のソフトウェアやハード ウェアの開発結制御システムの目的と構成果を共有していくか、ということに移っていくことにな

当初、遠隔制御を行うだけでも困難な時期もあったる。その中では、いかに一時的な流行 (Fad) に惑わされが 、現在では基礎となる技術の進歩によってシステムずに、しかし十分な機能を持った、寿命の長い制御シスの構築は容易になってきたかのように見える。しかし 、テムを作り上げるか、ということや、資源を共有するた

非常に性格の異なるさまざ まな加速器機器を統合して、
めには、まず加速器自体の定義から始める必要がある、 期待したビームの生成に結び付けることは、まだ確立さというような議論も行われた。
れたとは言えない。加速器や制御システムが大きくなる
その後、SSC2 が LANL と ANL/APS で開発された

につれ 、加速器が目標とした成果を得るために、制御シ

EPICS[10] を採用すると宣言したこともあって、EPICS

ステムの理念や方法論を正し く持つことはますます重を基礎とした資源の共有形態が模索されることになる。 要になってきている。
EPICS という共有可能な具体的な実装例を得たことに2.2.1 制御システムに対する要求仕様
より、ソフトウェア資源の国際的な協力開発にはずみがひとことで言えば 、加速器の制御の目標は 、信頼性つくことになった。この成果を、日本では KEKB リンが高く、かつ柔軟な制御処理の機構を道具として加速器

グの制御システムが積極的に利用している [11] 。
ところで、制御システムにおいてもオブジェクト指向に提供するところにある。通常、そのために複数のサブの設計やプ ログ ラミングなど ソフトウェア技術の発展

システムを統合して 、全体の制御システムを構成するの成果の取り込みについては、有効性は認識されていたことになる。ひとつのサブシステムは 、複合加速器のものの、独自の計算機環境や、実時間処理などのために場合、そのなかのひとつの加速器の制御を担当したり、制約を受け、大規模に行われることが少なかった。オブ真空システムのような機器グループを担当したりする。

ジェクト指向設計についてはなんらかの形で取り入れて全体のシステムは、通常はサブシステムの詳細を隠しているところが多かったが 、システム全体でオブジェクト

加速器全体を簡潔に表現するが 、求められれば 、個々の指向プログラミングを活用することが難しかった。この機器の詳細まで的確に提供できる必要がある。
このような制御システムの基本的な機能としては次点については、まず、上位層、つまりアプリケーションのようなものがある。

ソフトウェアに近い部分から CORBA や、Jefferson-Labの提唱する cdev[12] などを基礎としての利用が浸透し 加速器のオペレータや機器の担当者に対して、適当なグラフィカルインターフェースをもって、簡潔な情報と詳細な情報の双方をいつでも提供すること。
 加速器機器に対して、適当な実時間処理を実行し 、
ビームフィード バックなど の加速器の性能を高めつつある。
また、安価になったパーソナルコンピュータ (PC) の
1 当初はワークショップと呼んでいた。
2 残念ながら、その後 ICALEPCS93 の開催期間中にプロジェクトの中止が知らされた。

2

るための操作を可能にすること。

アプリケーションソフトウェアで機能を補わなければな

 現実の加速器と対比させながら 、加速器のモデリ
ングやシミュレーションを行えるような環境を提供すること。
 新し い問題が見つかったときに 、解決のための新しい制御処理を効果的に追加するための環境が用意されていること。
 個々の機器の間や時間との間でのちに相関解析が行うことができるように、情報を蓄積すること。
 予期しない事態が起ったときに 、適当な措置を講じたり、オペレータに報告したりする、いわゆるアラームの機能を持つこと。
 関連する他の施設や研究者、技術者、利用者などとの間に適当な情報交換を行い、また技術や成果の共有の手段を提供すること。

らない。
さらに、これらを実装する環境として、

 基本言語としてのコンパイラ言語
 プロトタイプ開発に用いるスクリプト言語
 データベース環境
 グラフィカルユーザインターフェース (GUI) 全体の構成を 2 階層のみにするのか 、多階層にするのか IP などの一対一の通信を基本とするのか、リフレ
クティブ メモリなどにより情報を共有させるのか フィールド バスに何を使うのかなどを選択する必要がある。

2.2.3
概略の構成は図 1 のようなものとなる。これらを実現さ

線形加速器の制御システムせるための実装方法は、さまざ まなソフトウェア資源が線形加速器の制御を考える際には、リング型加速器の共有されるようになった現在でも加速器によって異なっようなビームの自己安定化の仕組みがないために、制御ている。

システムは必ず必要になる、ということを考慮しなくてはならない。また通常、線形加速器はパルス運転される

High-Level
Beam
Controls

Operator Interface

Application
Development
Environment

ので、パルス毎の処理の可能性も考慮しておかなくてはならない。直線的に長いということが、装置に対して制Link toOther Systems

High Speed Central Network

Relational
Database

限を与える場合もある。リング型加速器ではひとつの電源が複数の電磁石に接続されるなど 、装置と名前の対応

Field Networks

が複雑になりがちだが、線形加速器ではそれぞれの場所

Equipment Controls — Beam Instrumentation

でエネルギーが異なることもあり、名前付けは比較的単

Accelerator Equipment

純となる。しかし 、そのエネルギーの測定が困難である
ことから、正確なモデリングも困難になる場合が多い。

図 1: 典型的な制御システムの構成

2.2.2

制御システムの内部機能上に挙げたような制御システムの基本機能を実現さ

3

KEK 電子入射器の制御の概要

3.1

入射器の制御の設計せるためには 、アプ リケーションソフトウェアに対して、次のような制御システムの内部機能（プリミティブ

API ）を持っている必要があると思われる。

KEK 電子入射器の制御システムは、古いシステムが1982 年から運転に使用されたが [4] 、1990 年頃から更新後のシステムの設計が始まり、1993 年に更新が実施

 要求されたときに 、同期または非同期で情報を提供できる
 定期的に情報を提供できる 状態が変わったときに報告できる
 高速応答するために適当な方法で情報を一時保持できる
 多数の情報を同時に処理できる
 情報を長期保存できるされて [8, 9] 、その後毎年改善されている。Unix 計算機
をサーバとして現場の装置コントローラを統括するシ
ステムになっており、それらの間の通信に TCP や UDPを元にした独自開発の RPC (Remote Procedure Call) を使用している。
設計においては 、前節に述べたような条件を満たす
ように、いくつかの方針をおいた。つまり、現存する制御システムはこれらのうち、すべてまたは一部の機能を実現している。機能が充分でない場合には、

3

 できるだけ国際標準や業界標準の規格を採用する。

 現場の装置コントローラは TCP/IP ネットワークに接続できることとする。

中間層には 、電磁石など の抽象化された加速器装置を表現するサーバソフトウェアがおかれている。それぞれは実際のハード ウェアを扱うためにいくつかの下位層

前者は 、柔軟性や拡張性を維持するために重要と考えのサーバを利用する。以下ではこの層を上位層と呼ぶこられ 、また将来の更新を容易にすると期待される。後者とがある。

は、以前は重視されていた統一された装置コントローラ

最上位の運転プログラムは実際の入射器のビ ーム運をやめることを意味するが 、あとで述べるようなソフト

転を行う。先に述べた RPC によって制御ネットワーク

ウェア構成によって、装置に応じて、また最新の技術を上のどの計算機からでも、制御許可の登録があれば 、運利用しながらコントローラを選択できることになる。

転操作を行うことができる。
さらに 、他の環境と情報を交換するために 、中間層のサーバの上にいくつかのゲートウェイソフトウェアが構築されている。例えば 、KEKB リングで使われている EPICS 環境のための Channel Access サーバ [15] や、Web ブラウザ経由で蓄積情報を取り出すための CORBA
サーバ [16] などが実際に運転に利用されている。

3.3

装置コントローラ

現場での装置の制御には、既に 20 年を経過した 8-bit

図 2: システム内の処理の論理的な構成

マイクロコンピュータを内蔵したコントローラや、毎年のように現れる新しい技術を利用したコントローラなど全体の模式図を図 2 と図 3 に示す。まず、この節で多数を利用している。1993 年の制御システムの更新時

概要を示し 、次節以降で詳細を解説する、制御システムには主なコントローラはそのまま使い続けたが 、KEKBと関連の深いタイミングシステムは第 7 節で解説するに向けた増強時には 、多数のコントローラが更新されが、合わせて論じられることの多い人および加速器の保た。それらは、個々の装置の要求仕様に合わせ、VME 、

護安全システムについてはこの稿では扱わない。

VXI 、CAMAC 、PLC (Plogrammable Logic Controller) 、PC などの技術で構成されている。速度的な要求が厳し
くないものについては、TCP/IP 通信が可能な、PLC が多数導入されいくつかの意味で省力化に役立っている[17, 18] 。

3.4

中央制御計算機とネットワーク

中央制御計算機として Unix クラスタサーバといくつかの Unix 計算機が主な中間層サーバと上位の運転ソフ
トウェアの処理を行っている。クラスタサーバは耐障害性、可用性の高いシステムの運用を可能にしているが 、

図 3: システムのハード ウェアの物理的な構成

さらに制御ソフトウェアは複数の計算機間で冗長性を持って運用されている。

3.2

入射器の制御の全体構成

制御用の計算機ネットワークは、FDDI バックボーン

システムは大きくわけて図 2 のように 3 つのソフトと多数の Ethernet セグ メントから構成されており、そウェアの階層から構成されている。下位層は 、例えばれらは星型の多階層トポロジで接続されている。現場の16bit の接点信号のような、異なる種類の制御ハードウェ
アに応じて用意されており、障害復旧などを含めたハーコントローラは 、パルス運転をするクライストロンモ
ジュレータのノイズを避けるために、すべて光 Ethernet

ドウェアの詳細を表現するが 、通常は上位層からは隠蔽(10BaseFL/100BaseFx) で接続されており、また 、中央されている。

に近い階層の接続は冗長接続をしてある。

4

理系であり、ミニコンピュータ間は専用の光ファイバー

 十分高速な通信ネットワークを持つこと
電子入射器は物理的に広い範囲 (500m) に機器が分散しているので 、この距離スケールで十分高速な
通信ネットワークが必要である。
 拡張・変更に即応できること
電子入射器は、運転用と同時に研究用の加速器でもあり、日々どこかで改良・テストが行われている。
したがってその制御系も、機器の拡張・変更に対して即応できる flexibility があることが望まれる。

ネットワーク (Loop-1) で相互接続されていた [4, 20] 。

これらの点を考慮して設計・構築した制御系は、

4

ハード ウェア構成

4.1

歴史的経緯

1982 年から運転に使用された初代制御系は、ミニコン
ピュータ（三菱 MELCOM 70/30 ）8 台と約 300 の micro-

processor ベースのローカルコントローラからなる分散処

しかし 、80 年代末にはミニコンピュータの保守や計算

 Main Computer の Unix 計算機
 front-end の VME-bus 計算機
 operator’s interface の PC と touch panel

能力不足などの問題が顕在化し 、1990 年頃から制御系を更新するべく調査・研究を始めた [7, 8] 。1993 年 9 月には、計算機やネットワークなど 基幹部を新しくした２代目制御系での運転を開始したが [21, 9, 22] 、人員や予などの構成要素を、算の不足からローカルコントローラはそのまま継続し 標準 network である Ethetnet (TCP/IP protocol)て利用することとした。その後、基幹計算機や制御ソフトの拡張・改修を重ねつつ [23, 24] 、ローカルコント

で相互接続した形態になった。その後の拡張・整備をローラも順次更新し [25, 18] 、現在に至っている。

経た結果、現在では図 3 のような構成に至ったわけである。

以上の経緯を表 1 に示す。

主計算機

(OS)
network(response)
front-end
andlocalcontroller

1982 年MELCOM
70/30
RealtimeOS
専用光ファイバ(5Mbps)
100ms
MELCOM
70/30＋ CAMACm.processor

1993 年workstation
Unix
Ethernet(10Mbps)
1-10ms
VME-buscomputer(680x0)m.processor

4.3

現在 (2002 年)
同左

構成要素

図 3 で示される個々の構成要素を追ってみよう。

4.3.1

FDDI/switch＋ Ethernet(10-100M)
0.1-数 ms
VME/VXI,CAMAC,
PC(linux,Win)
PLC

Main Computer Systems

1993 年の２代目制御系の運用は、Unix 計算機１台のみ（ 名前 peach 、運転・開発兼用、maple 導入後は運転専用）で始まった。その後は多数の Unix 計算機を導入してきたが 、現在は運転用３台と開発用２台の陣容になっている（ 表 2 ）。運転機が複数あるのは、負荷分散と redundancy 確保のためである。

表 1: 入射器制御システムの歴史的変遷

4.2

設計方針と全体構成

1993 年の制御系の更新に当たっては、以下の設計方針に従った。

 ハード ・ソフトとも業界標準を採用
加速器およびその制御系は、通常 10 年以上継続して使用される。このため特定の計算機システムに依存する設計では 、その計算機の親会社の方針の変化の影響を受け、好ましくない。また、個々の計算機寿命は 5–10 年と加速器寿命より短いため計算機を更新する日は必ず来る。業界標準の採用で、将来の計算機更新が楽になると期待できる。

名前

用途

機種

導入時期

状態

peach
lime
maple
grape
almondplum
lycheepoplarorange

運転
Ｘ表示
開発
運転
開発
運転
運転
運転
開発

DECstn.(Ultrix)
DECstn.(Ultrix)
DECstn.(Ultrix)
DECalpha(True64)
DECalpha(True64)
DECalpha(True64)
Compaq(True64)
Compaq(True64)
Compaq(True64)

Nov.1990
Oct.1991
Oct.1992
Mar.1994
Mar.1996
Mar.1996
Aug.1999
Aug.2001
Aug.2001

引退
引退
引退
引退

表 2: 基幹 Unix 計算機の導入
基幹計算機システム用の運転プ ログラムやデータを安全に格納するために、1994 年には早くも２ GBx ７台のデ ィスクアレ イ装置 (RAID) が導入されている3 。現
3 ただし最初の RAID システムはたびたび故障し 、大事なファイルが消えるなどして泣かされた。

5

在では 100GB クラスの RAID システムが２式あるが 、 エアへの迅速な対応が 、Windows 環境では難しかった
いずれも２系統の親計算機 (Unix) を持たせ、計算機保からである。また、KEKB リング用シミュレーション用守の際も同時に止めないことで完全な不停止サービ スに開発されたＸ-window 向けの SAD script が電子入射4を実現している 。

4.3.2

器にも応用できるようになり、Ｘ端末で走る運転アプリ
ケーションはどんどん増えていった。

Operator Interfaces and Applications

ところで、EPICS ツールキットを使った KEKB リン

Operator Interfaces は 、a) Windows PC（ Visual Basic

グの制御システムは電子入射器制御系とは独立なシスプログラム用）、b) タッチパネル、および c) Ｘ端末（Ｘ-テムである。しかし 、リング側運転アプ リケーション

window アプ リ用）、の３種類の混成になっている。運から電子入射器のデータが必要な場合がままあるため、転時の写真を図 4 に示す。

Channnel Access Gateway が用意されている [15] （ 図 3
右上）
。

4.3.3

Local Controllers

1993 年の制御系更新時点では、フロントエンド 部を
CAMAC から VME に移行、しかし micro-processor ベースのローカルコントローラはそのまま継続利用、という方針を取った（ 表 1 参照）。各セクタに１台づつ、計８台（１年後に９台）の VME-bus 計算機（ 68040 25MHz,

OS-9 v2.4 ）が設置された。OS-9 はリアルタイム性とある程度の stand-alone 開発環境を合わせ持つ OS で、当時入手できた他のリアルタイム OS に比べ安価であったため採用した。各 VME で約 50 の運転プログラムが メ
図 4: Operator’s interfaces (photo)

モリに常駐（ 4MB 中 3.5MB 程度占有）し 、cpu 稼働率
は平均して 10%程度であった。

電子入射器では、80 年代末から DOS PC をオペレー

しかし 、導入以来 15 年以上の時間がたってローカル

タコンソールとして導入する [26] など 、早くから PC のコントローラの保守が困難になってきた。各機器のロー利用を行ってきた。PC がコンソールに利用されたのは、 カルコントローラは、単純な IO 数 100 点と簡単なロジッ
運転業務に必要なグラフィックや漢字のある画面作成に、 クが必要である。また、上流の制御計算機と何らかの通基幹計算機の Unix より PC のソフト開発環境が優れてい信が出来なくてはならない。ローカルコントローラ更新

ると判断したからである。 1996 年に DOS から Windows

時の機種選定は各機器の担当者が行ったが、結果的にクへ移行し 、今日に至っている [19, 27, 28] 。現在、PC コ

ライストロン 、電磁石電源、真空の３機器で PLC（ 横ンソールは WindowsNT 4（ 一部 Windows2000 ）の PC

河 FA-M3 ）が選定された [17, 31, 32, 18] 。PLC は、単純

約 10 式からなる。加速器機器の全体監視や単純操作のIO では VME などと比較して安価であり、ラダーで簡ほか、電子運転ログブック [29] が日々利用されている。 単な前処理が可能である。また横河 FA-M3 は、ネット
タッチパネルとノブを用いた操作システムは初代制 ワーク通信機能を他社 PLC と比較検討した結果、我々
御系から用意されていたが 、現在使用されているのはの制御システムに組み込みやすい UDP プロトコルが実

DOS PC と PCTCP ソフトウエアライブラリを利用した装されていた。1993 年以降の制御機器ごとのローカルもので 、1991 年に最初のセットが導入された。その後コントローラの更新を、表 3 に整理した 5 。

表示器がカラー化され 、６式が導入された [30] 。現在でなお、Trigger-delay の新ローカルコントローラにはもノブを用いた直感的な操作はオペレータに好まれてネットワーク機能つき CAMAC が選定されたが 、そのおり、頻繁に利用されている。

後 VME module の導入に移行している。当初 CAMACKEKB 計画に対応した 1998 年以後の新規運転アプリが選ばれたのは 、必要な機能を持つ市販モジュールがケーションプログラムは、主に Tck/TK (Unix 計算機) でCAMAC でしか見つからなかったためである [57] 。ま開発されＸ端末で表示された [45, 47, 51, 52] 。これは 、 た、BPM（ビームモニタ）用には VME が選定された。
KEKB 電子入射器改造に伴って必要になったソフトウ BPM の場合複雑な前処理ソフトが必要で、PLC では予
4 計画停電時および重要な RAID 設定変更時には停止する

5 更新の事情は [25, 18] でも説明されている。

6

93 年以前

Klystron
70 台

CAMAC −
m.processor

Magnet
500 台

CAMAC −
m.processor

Vacuum
280 台

CAMAC −
m.processor

Trigger
16 式
140 信号
BPM
90 式

CAMAC −
m.processor

93 年-移行期(移行時期)
VME −m.processor(’97-’98)
VME −m.processor(’96-’00)
VME −m.processor(’96-’97)
VME −m.processor(’97-’02)

無し

現在

100 Mbps

機器

PLC
70 台

100 Mbps
10 Mbps

PLC
50 台

10 Mbps

PLC
18 台
CAMAC,
11 台
VME 5 式VME
19 台

10 Mbps(’97 新規)

表 3: 制御機器とローカルコントローラ
図 5: 制御ネットワークのセグ メント
定する機能の実現は困難と判断した [33, 34] 。さらに、クライストロン波形取り込みのためには VXI が [35] 、 4.4.1
また一部の特殊な用途向けに GPIB/RS232C のインター

ネットワークがバス型であると 7 、障害箇所の特定がフェースも準備されている。

4.3.4

ネット ワーク形態

著し く困難になることを経験している。障害の場所特定や回復の容易さから、加速器制御のような大規模ネッ

Network Systems

トワークのトポロジはスター型が望ましい。現制御系の２代目制御系用に 1993 年以降導入されたネットワー

ネットワークも、基本的にスター型である。

クは、Ethernet や FDDI など国際標準規格に従ったもの

また、制御機器グループ別にできるだけ独立のスターである。また、通信規約には業界標準の TCP/IP (TCP 及型ネットワークを用意し 、一つの系統に障害が発生して

6

び UDP) を使用している 。標準品の採用により、ネッも影響が他に及ばないようにすると同時に、トラフィッ

トワークの保守や拡張を安価に行えるようになった。

クの分離も行っている。一つのグループ ネットワーク

現在の制御ネットワークは約５０のセグ メントに分の内部でも、スイッチングハブやブ リッジを使用して、割され 、電子入射器棟全域と KEK 所内の何ヶ所かをカ

トラフィックの局所的な飽和による効率の低下を防ぐよ

バーしている。これらのセグ メントは 100Mbps の FDDI

う、ネットワークセグ メントを構成する。この目的のた

バックボーンを持つ中央スイッチングハブで集中管理しめにもスター型トポロジは有利である。

ている。セグ メントを分類すれば 、a) FDDI に直結され4.4.2

た Unix 計算機 (100Mbps) 、b) 中央 Hub に直結した制御

冗長性

室周辺の計算機セグ メント (10/100Mbps) 、c) 中央から

ネットワークに障害が発生した時、スター型トポロジ

スター型配線（ 10BaseFL ＝光ファイバ回線）で接続さの採用により障害発見は早くなるが 、制御機能の一時れた各セクタのセグ メント (10Mbps) 、などがある（ 図

停止は避けられない。そこで、経済的に許す限りネット5 ）。制御ネットワークについては 、次節でさらに考察

ワークに冗長性を持たせている。

を行う。

基幹部分で使われている FDDI はその規格の中に２重化が含まれており、１箇所の障害が全体に影響を与え

4.4

制御ネットワーク

ることはない。制御系の主要部分は FDDI で結ばれているので、信頼性は高い8 。

現在の制御系では、制御ネットワークの障害は電子入

中央から各セクタへの接続についても、スター型配射器運転停止に直結してしまう。ネットワークを運転期

7 90 年代前半の Yellow cable (10Base5) はバス型の例。

間中安定に運用することは極めて重要で、そのためにい8 最近では大規模なネットワークは GbE (Giga-bit-Ethernet) を利用することが多いが 、FDDI のような冗長性は無い。我々は FDDI の高
信頼性を経験してきたが 、維持費用の点から近い将来 GbE に移行せ
ざ るを得ないと考えている。

ろいろな工夫がはかられている。
6 初代制御システムでは、専用光回線と独自の通信規約を使用した。

7

線を２重に張り、冗長性を持った光トランシーバに接続

4.5

した。このような接続は、各機器のグループネットワー

現在の制御系には、電子入射器のほぼ全部の制御機器

クについてそれぞれ約 15 箇所の中継点で行っている。

4.4.3

信号（ 約 5000 点、10kB ）を監視する履歴情報記録サブシステムが組み込まれている [36, 37] 。信号の変動を約

光ファイバ使用による耐ノイズ性

１秒の周期で監視し 、変化があったときのみ記録をファ

電子入射器では、約 60 台の高出力クライストロンモ

イルに残している。現在 klystron 、magnet 、真空、など

ジュレータがギャラリーに配置され 、それぞれが強烈なが対象で、BPM は準備中である。履歴サブシステムは

電磁パルスノイズを出す。長い信号線を引かざるを得な

1993 年時点では VME/OS-9 ベースのシステムだったが、い制御ネットワークでは、このノイズの影響は深刻であKEKB 計画で導入された PLC に更新された機器分が対応できなかった。1999 年夏に PLC 更新分を Linux PC

る。このため、中央から各セクターの中継ボックスを経由して制御機器まで、ネットワーク配線は全て光ファイでデータ収集する仕組みが整備され [28, 38] 、履歴サブ

バ伝送 (10BaseFL 規格）で行っている。

4.4.4

履歴（ Archive ）システム

システムも再開した。クライストロンを例にとると、１

研究所ネット ワークとのリンク

台のクライストロン当り 18 個の信号 (全体では約 1200

電子入射器の制御ネットワークは、研究所ネットワーの信号) を１秒弱の周期で監視している。履歴ファイル

ク (KEK 所内ネット ) とは独立に運用され 、物理的にもは各クライストロン毎に出来、クライストロン全体では別物である。しかし制御ネットワークは利用できる場所

３か月で数 GB 、電子入射器全体で 4–5GB の大きさにが電子入射器棟に限定されるので、ど うしても所内ネッなる。

ト側の計算機から電子入射器の状態を見たくなる場合記録として残る履歴ファイルは ASCII 文字列の集合体がある。そこで、開発用計算機１台を所内ネットと制御の形である。その量が膨大なため、必要な情報をファイ

ネットワークの両方に接続し 、機器状態の読み出しのみ

ルから引き出すことは単純ではない。そこで、履歴情報

可能 (状態変更は出来ない) になるよう設定した。このを簡単にグラフ化できるよう、市販の graphic package11

結果、所内ネット側から加速器機器の状態読み出しが可を採用して dev hist と呼ばれる汎用ツールを開発した。

能になっている。また、この計算機を通して、制御ネッ

dev hist は制御用 Unix 計算機で動作する。メニュで表示すべき機器を選び 、ボタンやメニューで表示期間を指トワーク側からプ リンターなど 研究所共有の資源の利定する。図 6 は、その外観である。dev hist は 1996 年

用を可能にしている。

から使われ始め、もっぱらトラブルが起こった時に障害

4.4.5

運転時のネット ワークト ラフィック

発生時刻前後の機器の状態を調査するのに利用されている。障害を吟味、同定するのに絶大な威力を発揮する

ネットワークトラフィックは特定のセグ メントに集中しているわけではない。一例として、表 4 に図 5 で示場合がある。また、一定期間中の制御機器の傾向（トレしたセグ メントのネットワークトラフィックの実測値をンド ）を調べることも可能である。

示すが 、すべて 10Mbps に比べて 2-3 桁小さい9 , 10 。現状のトラフィック量であれば 、既存のネットワーク容量で十分と言える。
network
segment
RF-1A

traffic
frames/s (kB/s)
29 (2.8)

RF-CB

170 (16)

VME-1B

35 (6.9)

VME-CA

26 (6.3)

devicesin the segment
klystron(1sector 1st-half)
klystron(Csector 2nd-half)
BPM, vacuum(1sector 2nd-half)
BPM, vac, magnet(Csector 1st-half)

図 6: 機器履歴表示ツール dev hist の外観
表 4: 典型的ネットワークトラフィック
クライストロンと真空については、dev hist のグラフ
9 1998 年 10 月の測定。現在はこの値より大きいと推測される。

化ルーチンを呼ぶ Web 画面が 2000 年から利用可能に

10 表 4 中、RF-CB のトラフィックが多いのは、クライストロン波形
監視プログラム（Ｘ -window ベース）が走っていたため。

11 PV-WAVE。Visual Numerics 社の製品。

8

なった [38] 。検索条件が dev hist に比べ制限されるが 、Web を採用したことで、「 誰でも (Web が使える職員なら ) 、どこでも (居室や自宅でも) 、いつでも (制御グルー

5.2

設計方針と全体構成

現制御系の制御サービ ス（いわゆるサーバ層）は、加速器装置のコントローラの物理的な処理を表現する下

プ職員が居なくても) 」クライストロン・真空の履歴情

位層 (Lower level servers) 、及び加速器装置の論理的な報が得られる。多くの電子入射器職員にとって、無くて処理を表現する上位層 (Middle level servers) 、から構成はならないシステムになっている。

されている。サーバ層が２層に分かれている点は、他のなお、歴史的経緯により、電子入射器にはクライスト

加速器制御系ではあまりみられない特徴である。下位

ロンや真空以外にも異なる仕様の履歴システムが多数層と上位層、及び上位層とアプリケーションソフトウェ

存在する12 。これらを統一的に扱えるように、CORBA

ア層 (Upper level programs) の間は、ネットワークにつ（あるいは XML ）層を wrap して共通 API を整備し 、上いて透過な RPC (Remote Procedure Call) によって接続

位アプリケーションを目的別に共通化しようという研究されるが、ソフトウェア開発者は通常その存在を意識すが続けられている [16, 40, 39] 。

ることはない。これらの階層構造は 、図 2 に示されている。
上位層サーバは加速器構成要素に対応しており、Unix
計算機上で走っている。これら上位層のサーバは静的

5

ソフト ウェア構成

データベースに従って下位層のサーバと通信し 、キャッ

5.1

歴史的経緯

シング・単位換算や障害処理を行なう。下位層は基本的

IO (VME module) やローカルコントローラに対応して初代制御系では、ミニコンピュータと専用ネットワー

いる。このようにサーバ層を２層構造にしたのは、初代

クは制御メッセージの通信システムの交換機と考えら制御系で問題になったコントローラ仕様の違いを下位れた。例えば主制御卓のタッチパネルを操作すると、制御系（ 制御卓用ミニコン –ネットワーク–現場ミニコン ）を経由して制御メッセージが現場のローカルコントロー

サーバ層で隠蔽し 、アプリケーション層に影響を与えないようにという考えからである。また、ローカルコント
ローラは 1993 年の新制御系の運用開始移行時間をかけラに届き、目的の機器の設定が行われた。また、その結て徐々に更新したが（ 4.3.3 節および表 3 参照）、それに果としての現場機器の状態遷移は、逆方向に制御系を経伴って上位層は新しい下位層コントローラに対応した

由して状態表示プログラムに届いた。その round-trip 時

機能拡張を行う必要があった。しかし 、上位層とアプリ間は、100ms と実測されている [4] 。

ケーションソフトウェア層の間の取り決めについての変初代制御系の時代、年月が経過するにつれ改造された仕様の異なるコントローラが追加導入されていった13が、個々のアプ リケーションがコントローラの違いを記述

更は最小限に押えたため、開発済みのアプリケーション
は新旧のローカルコントローラが混在した移行期もほとんど 変更なしに継続して利用できた。これも２層構造して対応していた。当時はアプ リケーション数が少なの特徴が生かされた結果といえるだろう。現制御系で使かったとはいえ、機器の追加や変更のたびにコーディン

用可能な上位・下位サーバの説明は、5.3.4 節に示す。

グが必要で、迅速な対応は困難であった。また、当時のサーバやアプ リケーションの間のプロセス間通信にネットワーク伝送系の信頼度は今日的な感覚では低かっ

は、設計当時 defact standard になりつつあった TCP/IP プ

た。機器操作が うまくいかない場合、コントローラに

ロトコルを使い、専用の RPC を開発した [41] 。TCP/IP

メッセージが届かないのか、あるいは状態が変わったとの採用は、前述した多種多様な計算機機種が混在した状

いうデータが上位に上がってこないのか、障害の場所の況で相互通信を可能にするためにも最善の策と考えら

切り分けが困難だった。さらに、初代制御系のミニコンれた。

は メモリ制限から新規のプログ ラムを追加することはほとんど無理だった。このため現制御系の設計を始めた

1990 年頃には、初代制御系の能力不足を補うためのサブシステムが多数導入されたが [7, 8] 、困ったことに多種多様な計算機機種が混在していた。

5.3

制御ソフトウェアの詳細

5.3.1

基本操作のモデル

制御系のソフトウェアは 、図 7 に示す簡略化された

12 例えば 、冷却水温度、ビーム電流記録、など 。

基本操作モデルを原則としている 14 。

13 例えば 1990 年ごろ、screen controller は３種類、magnet power-

supply controller は２種類 (firmware の違いによりソフト的にはもっと多種類) あった。

14 この節の内容は [22] にも説明がある。

9

手順１

5.3.2 table と log (database)

operator（ユーザー）は、制御しようとする特定の object（ 名前 name で区別される）に対し 、命令 com

制御系では、静的データベースとして管理 table 、運を送る。必要ならばその com に付随した設定値 value も併せて送られるが 、この場合は object の property が変転操作記録データベースとして log file を利用している。
（ 図 8）

更される。
手順２ａ

object の名前 (name) が実際にはど の VME のど のモ
ジュール、何チャンネルであるかといった対応付けは、送られた com が指定した object に正常に作

管理 table で管理されている。管理 table は通常の ASCII

用したならば 、return-code として 0 が operator に返さfile で 、エデ ィタによって修正・追加する。サーバは 、れる。com によっては object の property (value) も帰っ

operator の制御対象 (object) に関するハード ウェア情報て来る。

をこの table から得る。管理 table は制御機器毎に存在す
エラーが起こればそのエラーに対応した負値

るが 、NFS を利用してすべての計算機で同じものを参の return-code が返される。この場合、operator は return-

照している。各セクタの VME 計算機は、自分が担当す

手順２ｂcode を調べて何のエラーが発生したか知ることが出来るセクタ分だけを元 table から切り出したローカル table

る。

を持っており、VME で走る運転ソフトはこちらを参照
している。

結局 、operator(ユーザー) は 制御系に 対し て (com,

制御系が実際の機器制御に伴って出力する情報（ 制

name, value) の組の制御メッセージを送ってその回答(return-code, value) を得る、という手順を繰り返して実御記録、エラー、など ）は、操作記録 (log) に残される。

際の加速器を制御する。図 7 の例では、”TEST2”に対し情報記録のレベルは２つあり（ エラー関連のみ情報を

value を 25 に設定 (SET) し 、return-code 0(成功) を得て残すか、全てのアクセス記録を取るか ）、制御機器の種いる。

類に応じていずれかを設定している。操作記録も、管理
table 同様 VME 側と Unix 計算機で共有している17 。

図 7: Software model of the control system.
この基本操作モデルでは、operator は制御したい対象
をど う操作するかという点のみを考えればよく、途中経

図 8: Control message distribution (Lower level)

路 (Ethernet とか VME とか) のハード ウェアについて考えたり知識を要求されたりすることはない。また、RPC

5.3.3 制御メッセージの分配部分のネットワーク通信コードが単純になり、機器によ

上位層サーバの場合、client からの制御メッセージ

らず共通化できている [42] 。一方このモデルでは、あらかじめ整備された com のみで機器を操作することにな （ (com, name, value) の組）は直接サーバへ送られる。しり、設計によっては制限がうまれる15 。また、round-trip かし 、下位層サーバの場合、client からの制御メッセー
ジは 、２段階の処理プ ロセス（ ＝プログラム ）がある

が操作の基本単位なので、相手機器側に問題がある時や。client からの制御メッセージは、まず第１のプ
ネットワークに障害がある場合は、返答待ちのタイムア （ 図 8 ）
ロセス (message distributor) に送られる。第１のプ ロセ
ウト処理に時間がかかってしまう問題がある16 。
スは管理 table を参照して制御メッセージを目的の VME

15 例えば複数の property・object の同時一括変更がハード でサポー

かされていたので、これを反面教師としたという側面がある。
17 現在は、VME 側で発生した記録文字列は UDP で log マシン (Linuxマシン ) へ転送し 、Unix と共通の log に書き込んでいる。

トされていてもやりにくい。
16 現制御系の制御単位を round-trip にしたのは 、初代制御系では操作単位が one-way で、またネットワーク伝送系の信頼度の低さに泣

10

の第２のプロセスに転送するための郵便局であり、メッ

求は拒否し 、そのホスト名は log に記録される。まセージの転送以外何もしない。第２のプロセスはそれぞた、ホストによって特定の命令（多くの場合”GET”

れの VME で実際に制御を行う server process である。第など read-only コマンド ）のみ受け付ける設定が可

１プロセスと同じ管理 table を参照して、制御に必要な能である18 。

ハード ウェア情報を得ている。図 8 では片方向の矢印しか示していないが、server プロセスが用意した reply メッ

5.3.4 制御可能な機器

セージ（ (return-code, value) の組）は同じ 経路で client

制御系では 、前述のように制御対象となる機器を２まで帰される。また、第１・第２ process が出力した制御情報（エラー情報など ）は、同じ log に書き込まれる。
この様に２段階に分割したのは、プロセス数が多くなっ層に分類して考えている。
下位層は、VME module やローカルコントローラに対応する層である（ 表 5 ）。これらの要素は一部を除いてても単純な process の組合せで制御システムを構築した

ごく一般的なもので、電子入射器での制御以外にも広く方が保守上有利と判断したためである。実際、message

利用可能と考えられる。

distributor は全ての制御要素で同じものが使用されてい下位層の制御要素に対する命令 (com) は使用している（ 管理 table と log だけが異なる）。server プロセスは

る VME モジュールに特有のハード 仕様には依存しない

おのおのの VME で独立に走るが、NFS により同じ実行ように設計した。これは、将来保守上の理由などからモイメージをロードしている。

ジュールの機種変更が必要になっても、これらの制御要[参考] PLC の場合、事情はやや異なる。clientからの制御メッセージは message distributer か素を利用する上位プログラムに影響が及ばない様にすら各 PLC にメッセージが転送される。PLC の上位層は 、下位層の制御要素を利用して制御する機

UDP 通信モジュールは 、server として機能し器である（ 表 6 ）。上位層の制御要素は下位層の機器にて reply を返す。これらの相関関係は図 8 と同比べてより上位の概念で、電子入射器の加速器の構成要るためである。

じであるが 、管理 table の内容は別途ラダーに素に対応している。上位層のサーバは、下位層からみれ組み込まれ 、log への書き込みも起こらない。

ば 機器サービ スを要求する client である。ただし 5.3.1
節で示される機器の制御手順は、両方の層で全く同じでさらに、上位層・下位層の制御メッセージの分配に関ある。

して、以下のような特長が指摘できる。
制御要素
VMEmodule/PLC コマンド ・関数名
 socket の利用
16bit D-out
PVME501/07
out16/outreg
電子入射器では、歴史的に多種多様な計算機サブシ
16bit D-in
PVME501/04
in16/ingate
ステムが導入されてきた [7, 8] ため、プロセス間通12bit ADCPVME301,305
adc12
信には異なる計算機機種間でも通信可能な TCP/IP
12bit DACPVME323dac12
プ ロトコル (socket 関数) を採用した [41] 。また 、
delay
TD4V
td4v
socket 関連のパラメータを与えればサーバの RPC
GPIB
DVME-GPIB
gpib
部分のコード を半自動的に生成するテンプレート
loop2
CAMAC-loop2
loopcが開発され 、利用されている [42] 。
loop3
海津 8755
loop3
 ポート番号管理による非干渉性
PLC
Yew FA-M3
plc
電子入射器では，制御の対照となる機器が多種類あ
表 5: 制御可能な機器（ 下位層）
るが 、これまでに述べた message distributor, server,
管理 table, log はそれぞれの機器毎に独立に存在しており，異なる機器間ではお互いに干渉しない。この仕掛は，socket 通信で機器毎に異なるポート番号 5.3.5 user’s interface(service name) を割り当てることで実現している。
制御系とのインターフェースには、OS レベルのコマ
 security
ンドを利用する方法とＣ関数を利用する方法がある。こmessage distributor は、socket 接続を受け付ける際
れらは電子入射器運転用の Unix 計算機や VME 計算機に接続要求を出したホスト名を登録 table のものと18 この例が 5.4 節に示されている。
照合している。登録 table に無いホストからの接続要

11

制御要素

下位層要素

コマンド ・関数名

signal selector
screen mon.

D-out
D-out/D-in

coax
scrn

klystronmagnet

PLC
PLC

kly
mg

vacuum

PLC

vac

BPM
interlock

none
PLC

sp
intlk

trigger

td4v/loop3

trigb)VME ホスト名、c) ボード アドレス、d) 各ボード
でのチャンネル番号、を表している。
! [0] Injector!
806 - PM screen!
220,221 - PM cntroller!
202 - CM807 - WM
!namenodename base-addr
806
kannaduki fc4b0000
202
kannaduki fc4b0000
TEST0-1 kannaduki fc4b0000
807
kannaduki fc4b0000
TEST0-2 kannaduki fc4b0100
TEST0-3 kannaduki fc4b0100
220
kannaduki fc4b0100
221
kannaduki fc4b0100

表 6: 制御可能な機器（ 上位層)

(OS-9) で利用できる19ほか、整備すれば PC(Linux, MSDOS) でも利用可能である。

 コマンド 利用
制御系がインストールされた計算機では，機器を制御する OS レベルのコマンドが利用できる。コマン
ド は表 5・表 6 の機器それぞれに用意されている。
簡単なテスト、速度が要求されない場合にはコマン
ド 利用が便利である。

channel
0
1
2
3
0
1
2
3

 online manual
D-out service を利用する際のコマンド（Ｃ関数）名は、表 5 で示したように out16(または outreg) である。運転 Unix 計算機などで、オンラインマニュア
ルを呼び出すことが出来る（ 図 9 ）。

 Ｃ関数利用コマンドと同様Ｃ関数も表 5・表 6 の機器で用意されている。コマンド 利用に比べ速度や複雑な条件判断が可能になる点で利点がある。ユーザーは、用意された制御ライブラリをリンクすることで電子入射器制御プログラムを開発できる。
表 5・表 6 の機器それぞれの利用の際の具体的な情報
は、運転・開発マシン (表 2 参照) のオンラインマニュアルで得られる。一度概念を理解してしまえば 、Unix/Linux
環境でこれらを参照するスタイルがお手軽である。また、コマンド・Ｃ関数を利用した運転用アプリケーショ

図 9: Online manual example

ンは 、すでに多数開発され実際の運転で使用されている。運転ソフトウエアについては、６節で詳述する。

また、制御コマンドを引数無しで実行すれば簡単な

5.4ヘルプが表示される。out16 の場合を以下に示す。

Example(D-out)

grape[164]% out16
out16: specify com and/or name

この節では、機器制御の例を D-out service (16bit dig-ital output) で具体的に解説してみよう。

 管理 table
D-out service の 管 理 table の う ち 入 射 部
VME(kannaduki) に 関 す る 部 分 を 以 下 に 示 す。
ここでは２枚の digital board (計８ポ ート ) が 定
義され ている。各 field は 、左から a) ポート 名、
19 VME 計算機では担当するセクタのみ制御出来る。

12

out16 v3.1b - digital output (16bit) control
Usage:

Option:out16 com name [value] option ...
com- GET, SET, CLR, TBL
name - name of the port
value - value to be set (for SET)-h help message-xvalue in hexa
-dvalue in decimal

symbol definition(定義値)

意味

OUT E CM(-9)
OUT E BUS(-10)

共有メモリー使用不能

OUT E COMMAND(-11)
OUT E NAME(-12)

指定したコマンド com がおかしい

OUT E TBL(-15)

管理 table が読めない

OUT E TBLPARAM(-14)
OUT E MANYMODULE(-17)

管理 table のパラメータ不良

OUT E OUTRANGE(-26)

指定値は有効範囲外

OUT E SCLIB(-81)

SCLIB(network 通信) のエラー

OUT E NETPROT(-82)
OUT E SCOPEN(-83)

Linac 登録外、接続許可しない
out16-daemon に接続できないOUT E LIBRBUG(-20)

bug または version が合わない

Bus-trap エラー（ボード 不良）指定した name 名は存在しない

管理 table の登録 board 枚数が多すぎ

表 7: error codes for out16/outreg functions-ovalue in octal-lN
repeat N times-econtinue loop when eror-ssleep 1 sec. after each call-sT
sleep T-sec. after each call
Example: out16 SET TEST-1 64
out16 GET 200 -x -l100 -s

0grape[170]% outreg set test0-1 255 -dgrape[171]% outreg get test0-1 -d
# 10
進

# 8

る out errend() 関数を利用している。

このように制御系では全ての操作の記録を log に残進

377
grape[173]% outreg get test00-1

では対応するエラーメッセージを表示して exit す

15:24:14 grape> umdist-grape.1177:[331-80byte]-> com='SET' name='TEST0-1',
1 int's 0xff00,..
15:24:14 grape> umdist-kannaduki.4301:<- rtn=0 (no arguments)
15:35:22 grape> umdist-grape.1183:
undefined name 'TEST00-1'

# 初

期値

255
grape[172]% outreg get test0-1

outreg(または out16) 関数の return 値は正常なら 0だが 、表 7 のようなエラー値が有り得る。この例

 log「 コ マンド に よる操作例 」では grape からポ ート ”TEST0-1”に対して読み書きを行った。この例では、log として以下に示す記録が残る。

 コマンド による操作例
ここでは ”TEST0-1”を、outreg コマンドを使って初期値 0 から 255 に変更する例を示す。数値は default
では 8 進数表示、d-option で 10 進数表示である。
grape[169]% outreg get test0-1 -d｝

すことが出来、時刻・依頼元 (この例では grape)・依

# 間

違い例

頼先 (TEST0-1 at kannaduki) などを後からトレース

out16 v3.1b: illegal portname specified

することが出来る。ただし 、default 設定では D-out

service は読みだし (com=”GET”等) は残さない設定

 Ｃプログラムからの制御例
同様に、”TEST0-1”を 255 に変更するＣプログラム例を示す。

なので、上の記録には現れていない。

 security check
制御系は、依頼元ホストによって実行できる機能を制限している。例えば 、開発用計算機 (maple) では、
読みだし命令 (”GET”など ) は実行できるが機器に何等かの変更を加える命令は実行できない様に設定している。以下の例では、maple から ”TEST0-1”の値を読み出しているが変更には失敗している。

main()｛

inti, rtn;i = 255;# 255 設定
rtn = outreg( "SET", "TEST0-1", &i );if( rtn ＜ 0 )out\_errend( );printf( "suceeded" );13maple[200]% outreg get test0-1
377
maple[201]% outreg set test0-1 7
out16 v3.1b: fail to connect due to security

security check で引っかかった情報は操作記録と同様 log に記録される。

clientmess.dist.

serverround-trip

DECstation(peach)DECstation(peach)VME(saburo)16 ms

PC9801BA

DEC3000

VME

13 ms

(tpinj6)(grape)(saburo)AlphaServer(poplar)AlphaServer(poplar)

VME(hatsuhi)

6 ms

15:44:39 peach> umdist-maple.4464:[1918-80byte]-> com='SET' name='TEST0-1',
1 int's 0xfff8,..
表 9: round-trip time (UDP, 80byte)
15:44:40 peach> umdist-maple.4464:
com specified is not allowd from maple
15:44:40 peach> umdist-maple.4464:<- rtn=-82 (errr return) ランザクション ）を処理したか計算することができる。

1998 年から 2001 年までの４年間の推移を表 10 に示す。

5.5

制御メッセージの速度

典型的な例である D-out サービスで、制御メッセージの速度を測定した20 。

機器

total

total

total

total

[transactions/s]

Jun.98

Jun.99Jun.00

Jun.01

Klystron

5.3

4.6

18

27

表 8 は 、client(Unix 計算機など ) と VME 計算機のtr./s

server 間の、UDP プロトコルでの往復 (round-trip) 時間

Magnet

63
tr./s

70

24

23

Vacuum

no

no

45

2.1

data

data

tr./s

Trigger

0.028
tr./s

0.035

0.035

1.6

BPM

32

158

252

299

を測定した結果である。6–8 ms かかっている大半 (5 ms程度と推測) が 、相対的に CPU 能力の低い VME 計算
機での処理時間と考えられている21 。また、Unix 計算機のみでの簡単な通信テストでは、100byte 程度の制御メッセージを UDP プロトコルで往復させるのに 、ネッ
トワーク越しの２計算機間で 1ms 、同じ計算機内のプロセス間で 0.1ms 弱である。

tr./s

clientserverround-trip

DECstation5000(peach)VME(saburo)7 ms

PC9801BA(486,40MHz)

VME

8 ms

(tpinj6)(saburo)AlphaServer DS20E(poplar)

VME(hatsuhi)

表 10: 1998-2001 年の機器サーバトランザクション

この表から、a) トランザクション総量は毎年増加して2001 年には毎秒 350 に達していること 、また b) BPM(beam-position monitor) の処理量が圧倒的に多いこと 、

6 msなどが分かる。さらに解析すれば 、BPM へのトランザ
クションの半分以上が KEKB リング制御系からの寄与

表 8: round-trip time (UDP, 80byte)とわかり、トランザクション総量の増加は KEKB コミッ
ショニング活動と深くかかわっているとわかる [43, 44] 。

表 9 には運転状態での client と VME 間の制御メッセージ往復速度を示した。表 8 の条件と比較すると、a)message distrubutor が仲介する、b) security check が入っている、点が異なっている。mesage distributor が仲介す6

運転ソフト ウェアとビーム制御

ることによる時間増は 1 ms 以下と見積られている。

6.1

アプリケーションソフトウェア

5.6

運転中の機器サーバの負荷

これまで述べてきたように、入射器の制御システム

運転中に蓄積されたサーバ log を解析すれば 、それぞは、階層化された多数の要素から構成されているが 、されの機器サーバがどれだけの量の制御メッセージ（トらに安定した信頼性の高い運転を実現するために、制御機器や計算機、ネットワーク、ソフトウェアの質を高め

20 outreg の GET を 1000-10000 回程度 loop させて時間を測定。

る努力が払われてきた [45, 46] 。

21 なにぶん clock 25MHz ですから ..

14

Linac Beam Line Static Database("BTdimension")

このような制御シ ステムを基礎とし て 、1997 年にKEKB 入射に向けた増強後のコミッショニングが開始されてからは、上位のクライアントソフトウェアとしてIntermediate Files

さまざ まな運転用アプリケーションソフトウェアが構築(Initial Values)

Input Files for "Transport" / "SAD"("BTfile")

されてきた [47] 。それらの運転用ソフトウェアは主に、

Tcl[48] または SADscript[14] というスクリプト 言語で記述され 、X-Window 上の Tk ウィジェットを用いて画"SAD""Transport"[SAD computers] [Linac computers]

面上で操作が行なわれている。その数はビームスタディ(Magnetic fields)

や測定用のソフトウェアを含めて登録されているものだ
けで 150 ほどになっている。

6.2(Linac Layout, Mechanical /Effective Length, etc.)(Magnetic fields)(Acceleration fields)

Linac Controls

Linac Control Static
Database ("*.tbl")

情報の交換
Linac Accelerator

コミッショニングの直前やその最中においては、加速器の装置やその情報が日々更新される。それらの基本

図 10: シミュレーションソフトウェアと制御システムの情報は装置の担当グループが管理する場合が多いので 、 間の情報の流れ。
各担当グループ やコミッショニンググループと制御システムの間で情報が円滑に交換できるよう注意してい情報は加速器モデルとして意味のあるものになるようにる。例えば 、居室のパーソナルコンピュータからデータ

制御システム内でできるだけ変換をしている。例えば 、ベースを更新することができるように、標準のファイル

加速電界とか、磁場勾配といった情報がやりとりされる共有プロトコル（ Macintosh の AppleShare や Windowsことになる。しかし 、較正係数がまだ正確にわからないの NetBIOS-SMB ）をファイアウォール上の Unix 計算

ものも少からずあるので、ビームを使った較正などを進機でサービ スしている22 。

めているところである。

担当グループから制御システムに渡る情報はスプレッ

1998 年秋からの KEKB リングの運転においては入射ド シート（ Microsoft の Excel など ）の形を取る場合が器とリングの制御システムの間の協調も重要になった。

多い。現在は、新しい情報を実際の運転に使用するデー

KEKB リングの制御システムは EPICS [10] を採用した

タベースに反映させる手順は制御グループが担当してので 、入射器の制御システムの RPC 規約と、EPICS のいる。

Channel Access 規約の変換をするための Channel Access

また、加速器のシミュレーションソフトウェアともさ
まざまな情報を交換しなければならない。入射器で以前

Server というゲートウェイソフトウェアを準備している[15] 。SAD で書かれた一部のソフトウェアや KEKB 全から使用している TRANSPORT[49] は入出力をファイ

体のアラーム表示などにこのゲートウェイが利用されてルで行なうので、その規約と合わせるために入力ファイいる。

ルの準備や、出力ファイルの解釈を外部で行なわなくて

また、条件が整えば 、EPICS に限らない上位インターはならない。そこで、運転パラメータなどの制御システ

フェイスとして定義された cdev [12] や CORBA [16] のムを通して得られる動的な情報と、静的なデータベース

導入も将来の入射器の制御に有用であると考えており、とから入力ファイルを生成し 、計算を行なっている。

実装を進めている。これらを利用することによって、対

さらに、上に述べたように SAD も多数の運転用ソフ

象指向プログラミングを行なうことができ、国際協力のトウェアで使用されている。SAD はビームシミュレー

見地からもソフトウェアやアイデアの交換が促進できる

ションソフト ウェアではあるが 、Mathematica 相当のものと思われる。

SADscript というインタプリタ言語を持っており、また、
KEKB のコミッショニング以降、X-Window の GUI を6.3作る機能も追加されている。そこで SAD と入射器の制オペレータインタフェース

御システムの間では TRANSPORT と同様の比較的静的

KEKB 入射器のコミッショニングにおいては 、当初Windows の環境でソフトウェア開発が行なわれることな情報の他に、直接に入射器の制御機能を通して相互作が想定されていた。しかし 、Windows のコンソールと用して、柔軟な運転ソフトウェアが構築されている。

制御システムとの間にゲートウェイがおかれていたこと

制御システムとシミュレーションソフトウェアの間のなどが障害となって、途中からソフトウェアの開発が停

22 CAP や SAMBA という Freeware を使用している。

滞気味になってしまった。一方、ビームスタディや試験

15

には以前から X-Window 上の運転ソフトウェアが利用されていた [50] 。
そこで、コミッショニンググループ内で新しく作るソ
フトウェアは X-Window 上で Tk ウィジェットを利用して主に Tcl と SADscript で作成することになり、制御グ
ループも積極的に開発に関わった。ソフトウェア開発やデバッグのための環境や 、共通に利用するライブラリ
ルーチン 、運転時のソフトウェア自体の障害記録、などが用意されている。
いづれの言語からも入射器の制御との接続は単純で、またいづれもインタプ リタであるために開発、試験の繰り返し 期間が短縮され 、開発効率が大幅に向上したと思われる。特にこれまでシミュレーションプログラム
を実時間で動作させることは、試験的には可能であっても、現実にはさまざ まな困難があったが 、KEKB のコ
ミッショニング以降は複数の運転ソフトウェアで日常的

図 12: 相関プロットの例。さまざまな機器の情報の間でプロッ
トを作ることができ、また、関数を選んで最小二乗法によるフィットが行える。

に利用されるようになっている。

6.4

運転用アプリケーション
 バンチャ部シミュレータ。
 ビームオプティクス表示。
 Q-スキャンによるエミッタンス測定及びマッチング。
 4 台のワイヤスキャナによるエミッタンス測定及びマッチング。
 Isochronous かつ Achromatic な Arc 部の評価と補正。
 繰り返しによるビーム軌道補正。
 ローカルバンプによるウェイク場の補正。
 ビームモード 切り替え。
 Arc 部と終端部でのエネルギーフィード バック。
 多数の場所での軌道フィード バック。
 Downhill Simplex によるビームの最適化。

以上のような環境のもとで 、次のような運転用アプ
リケーションソフトウェアが開発されてきている。

図 11: 運転パラメータを保存、設定、比較するためのパネル。
多数のオプションを備えており、場所や種類によって機器を選択したり、ビームモード などを区別したりできる。データ
ベースは多数のプログラムで相互利用されている。

いずれのソフトウェアもだれもが操作できるように、
X-Window のグラフィカルユーザインターフェースを備えている。それらの例を図 11 、12 に示す。また 、入射器の安定化に寄与しているビームモード スイッチとフィード バックパネルについて次項で詳しく説明する。

 ビーム位置モニタのビームによる較正。
 ビーム位置モニタのビームによる精度評価。
 加速装置との対応付けをしたビーム軌道表示。
 ワイヤスキャナ上のビームの表示。
 ビームロス表示。
 エネルギーアナライザでのエネルギー分布の表示。
 エネルギー安定度の表示。
 能動的及び 受動的な各種パラ メータの相関プ ロッ
トと統計解析。
16

6.5

KEKB 入射器の安定化

KEKB 入射器のコミッショニングを開始したころは、
3.5 GeV 陽電子発生に使われる 10 nC の一次電子の安定な加速のために努力が払われ 、数々の技術改良により、これを達成することができた。しかし 、さらに実際の運転を行う上では、高品質のビームの再現性の問題が重要となってきた。同じビームを別の時間に再現しようとす
ると 、 微妙な運転パラメータの調整を必要とし 、時間がかかる上、だれでも調整できるわけではなかった。
解析を進めるうちに、気温、水温などの環境の変化、
モード 間で 10 倍以上異なるビーム特性の切り替え、意識的に変化させた他の運転パラメータ、などに対して、各機器のパラ メータの設定値からのずれが設計したときの許容値よりも大きい場合があることが指摘された。
そこで、各パラメータの、ビームに対する変動の許容度が詳しく調べられ、パラメータ設定の際にその許容値を満足させるための方法が検討された。
例えば 、コミッショニングは当初、通常運転とは別に部分的に行なわれたため、一部の電磁石は初期化が行なわれなかったり、消費時間を無視して消磁が行なわれたりした。しかし 、実際の切り替え運転では限られた時間
内に許容値内の磁場の設定が必要となるので、効率的な初期化の方法が開発された。具体的には、励磁特性を測定したときと同じ 、ゼロと最大値の間の電流設定ループ
を一度だけ回るように設定を行なうこととした。
これらの他に 、数多くの操作の中での単純な操作誤りに気付かず、問題の解析を困難にしている場合もしば
しば見受けられた。それらは、ソフトウェアで自動化することによってできるだけ避けることにした [52] 。
個々の機器の再現性の向上で対処できずに残ったビー

図 13: ビームモード スイッチパネルで 、KEKB e+ がを指定

ムの変動は、ビームを使ったエネルギーや軌道のフィーした状態。左の Check-button で項目の選択、非選択を変更でき、また Pull-down menu でパラメータファイルを選ぶことができる。右端は実行状態を表す。

ド バックで対処することとした [51] 。

6.5.1

ビーム・モード ・スイッチ

上に述べたように、4 つのビームモード 間の切り替え

各項目は、図 13 に示すようなパネルによってオペレー

においては、各加速器機器のパラメータの再現性と信頼タの判断でいつでも選択、非選択を変更でき、さらにそ性が重要である。パラメータ切り替えのために用意されの状態を保存しておくことができる。また、新しい項目

たソフトウェアは、現在では以下のような切り替え項目の追加は簡単なデータベースの変更によって行なうこを持っている。

とができる。もしも回復不可能な障害が起こった場合には、その旨が画面上に表示、記録され 、障害が取除かれ 電磁石の簡易初期化
 電磁石のパラメータ（ 主に電流値）設定
 rf のパラメータ（ 主に位相値）設定
 タイミングのパラメータ（ 主に待機モード ）設定
 電子銃のパラメータ設定
 陽電子ターゲットとシケインの操作
 ビームモニタの測定モード とダ イナミックレンジ
切り替え ビームプロファイルモニタの操作
 初期ビーム繰り返しの設定
 ビームトランスポートラインの選択
 下流の加速器の運転システムへの通知
 制御室での音声の発生
 機器の状態、パラメータの差分表示と記録
 各ビームモード のビームフィード バックの再起動た時にオペレータが再試行することができる。
パラ メータ設定と記した部分は 、直前の同じビ ーム
モードで使用したパラメータを通常使用するが、他のパラメータをオペレータの判断で選択することも可能になっている。これらのパラメータはフィードバックや手動の調整で毎回異なるため全て記録を残しており、また再使用が可能である。
電磁石の初期化については磁場の再現性、急激な変化に対する電磁石電源の許容度、AC 電源容量、通信時の誤り率と制御システムの下位層、上位層での再試行、切り替えソフトウェア側での再試行、など について繰
り返し試験が行なわれ 、改良されてきている。しかし 、
もっとも時間を消費する部分でもあるので、しばしば改善が行われている。

17

図 15: 動作しているフィードバックループの状態表示パネル。
多数のエネルギーや軌道のフィード バックの動作状態を監視している。

rf 位相を逆方向に変更する操作をアクチュエータとして利用する。また、軌道フィード バックでは、1 ベータト

図 14: フィード バックの例として 、R セクタのエネルギー
フィードバックの設定パネルとグラフ。運転時であってもフィードバックの設定パラメータは簡単な前処理、後処理を含めて変更可能で、また、ソフトウェアのほとんどの部分は他のフィード バックと共通となっている。

ロン 波長内でのビーム位置の重み付き平均をモニタ値として使用する。
ビームのフィード バックはビ ーム位置モニタが 1Hz

6.5.2

で読み出し 可能なので 、ソフトウェアの繰り返しはほ

ビーム・フィード バック・ループ

ぼ 1Hz で、振動を避けるためにゲインは低めで動作さ

現在使用されているフィード バックは 、加速器機器せている。

に閉じたフィード バック、ビームエネルギー のフィー

現在では 、エネルギーフィード バックが 6 ヶ所、軌

ドバック、そしてビーム軌道のフィードバックに分類さ道フィード バックが 30 ヶ所、機器のフィード バックがれる。それらの基本的なソフトウェアは共通になってい6 つ、常時使用されている。また、多数のフィード バッて、単純な PID 制御を行う以下のような部分から構成

クを管理するために、フィードバック状態表示やフィーされている。

ドバック記録のビューワなどのソフトウェアも用意され ビームモード やビーム電流などの条件の確認
 モニタ値の取得、時間移動平均、許容範囲の確認、その他の特別に指定された後処理
 変換係数とフィードバックゲインを適用したフィード バック量の計算、許容範囲の確認
 許容範囲の確認、特別に指定された前処理を施した値のアクチュエータへの設定
 全体の制御とグラフ表示、記録、他のプログラムとのインターフェース

ている。

6.6

ビーム運転ソフトウェアの効果

これらのソフトウェアはスクリプト言語で記述されているため、更新が容易で、しばしば運転中にも更新が行なわれる。また、他の運転用ソフトウェアと基本操作部分をライブラリルーチンとして共通化し 、統一された操作環境が提供されている。
ビームモード 切り替えソフトウェアは開発当初は毎日のように 、また現在でも頻繁に改良が加えられ 、信例えば 、エネルギーフィード バックでは 、分散の大頼性が高まっている。この自動化によって、一日あたりきい場所でのビーム位置をモニタとして使い、（エネル

約 50 回の切り替えも問題無く対応できるようになった。

ギー幅を増大させないように ）2 台のクライストロンのKEKB の蓄積ルミノシティに対して重要な切り替え時
18

間も通常 1 分程度になっている23 。

グの rf は非同期で 、入射タイミングはそれらの間の 2

また、フィードバックループを使用することによって、 重同期回路で生成されていた。しかし 、KEKB リングに入射されるビームはサブ ハーモニックバンチャ（ SHB ）加速器の状態や場所など にもよるが 、ビームの変動を長期間（ 6 時間程度）のものは 5 分の 1 程度に 、短期を用いて、入射器の単バンチとして加速され 、入射には間（ 1 分程度）のものは 約半分に減少させることができ30ps 以下（ リングの入射位相にして 5 度以下）の精度た。また、オペレータの操作を必要とせずにモード 切りが求めらるので、利用される複数の rf 周波数は表 11 、替え後も高品質なビームの維持が可能になった。また、 図 16 のように整数関係を持つことになった。
加速器の異常を発見するための指標にもなっている。
PurposeFundamental
Linac SHB1
Linac SHB2
Linac Main
KEKB Ring

これ らのシ ステムに よって 、下流の 加速器 、特にKEKB Belle の実験効率に大きく寄与している。コミッ
ショニングの詳細については、多数の報告がされている
ので 、そちらを参照してほしい [53, 54, 2] 。

Ratio
x11
x55
x275
x49

Frequency
10.38546 MHz
114.24 MHz
571.2 MHz
2856 MHz508.8873 MHz

表 11: KEKB 入射器の基本周波数

7タイミングシステム

7.1

入射器のタイミングシステム

SHB 1
Common

KEK の電子陽電子入射器のタイミングシステムは 、x 11

114.24 MHz

SHB 2
x5

10.385 MHzKEKB Ring rf
x 49

入射器内の電子銃、マイクロ波、及びビームモニタなどの 100 を超える機器に精度の高いタイミング信号を供

571.2 MHz508.89 MHz

Linac Mainx52856 MHz
Ring Revolution

5120

99.39 kHz

図 16: KEKB 用の各 rf 信号の関係。旋回周波数以外は入射器給している。ここにおいても、入射器の他の部分と同様

内で生成されている。

に、高い安定度を達成するためにさまざまな機構が導入されている [2] 。特に、KEKB 入射のためには、以前の

これらは入射器棟内に置かれた周波数分周逓倍器でTRISTAN プロジェクトに比べると格段に精度の高いタ生成され 、マイクロ波ド ライブシステムなどに分配さイミング信号が必要となるため、全面的なシステムのれている [55] 。タイミングシステムではこれらの周波再構築が行われた。リングの rf との同期精度の向上や、 数のうちあとで述べるように 114MHz と 571MHz をクロックとして利用しており、また、ビームタイミングはエネルギー増強のために入射器全体にわたって使用され10.39MHz から作られる。

たマイクロ波パルス圧縮器 (SLED) への信号供給に注意

これらの周波数は基本周波数（ 10MHz ）にして 0.1Hzが払われている。
このようなタイミングシステムは 、入射器内のさま単位で変更が可能で 、KEKB リングの周長が日格差な

ざまな機器と関連を持って動作するが 、主に制御グルー

どで変動した際に軌道補正のソフトウェアによって変更

プが担当しているので 、ここで解説をすることにする。 が行われる。

PF や PF-AR の入射に際しては約 2ns 幅の複数バン

7.2

タイミングシステムの構成チで加速しており、また条件が厳しくないので、リングの rf 周波数との同期は取っておらず、あとで述べるよ

入射器のタイミングシステムでは 、ビームタイミン

うに旋回周波数とだけ同期を取っている。

グ信号、マイクロ波発生用トリガ信号、ビームモニタ用
トリガ信号、などが必要に応じて精度よく生成されていこれらの rf 周波数とは別に、運転用パルスモジュレー

る。それらは基本信号の発生と分配機構、15 ヶ所の副タの繰り返し周波数（ビームの最大繰り返し周波数）でトリガステーションにおけるの遅延信号の生成機構などある 50Hz は、電源等のノイズの影響を低減させるためを通して加速器の各構成機器に供給されている。

に、商用周波数に同期させて生成している。

7.2.1

基本クロック

7.2.2

以前の TRISTAN 蓄積リングへの入射には、300ps 程ビームタイミング信号

ビームタイミングは 50Hz タイミングをリングの旋回

度のタイミング精度で十分であったため、入射器とリン周波数（ PF は 1.6MHz 、PF-AR は 0.8MHz ）に同期させて作っている。ビーム繰り返しは最大で 50Hz である

23 主に電磁石の初期化の時間

19

が 、分周して繰り返しを少くすることができる。さらに導かれ 、クロックとタイミング信号に再生される。さに、必要に応じてリングのバケットを選択する遅延が追らに 2 次的な副ト リガステーション 5 ヶ所にも導かれ

加される。

る。
（ 表 12 ）この仕組みによって、遅延信号が各トリガ
ステーションにおいて、ステップ 1.75ns 、精度約 10ps

KEKB については上に述べたように 、基本共通周波で生成できることになる。

数 10.39MHz に同期した上で、5120 個のうちのひとつのバケットを選択するので 、最大 0.5ms の遅延となる[56] 。
7.2.3

クロック及びタイミング信号の分配

以前の TRISTAN プロジェクトにおいては、ビーム以外のパルスマイクロ波生成等のためのタイミング 信号には 30ns 程度のジッターを持った非同期の遅延信号が主に使われていた。しかし 、KEKB においては安定度の要求と SLED を使用した高電界加速のために精度のStation
場所

Beam Station
A1 電子銃

1 次副 Station
Sub-booster

2 次副 Station
副制御室

数

1

9

5

クロック
の分離

TD4R

TriggerReceiver

1 次副 Station
より

遅延信号
の発生

TD4R

TD4

TD4V

Field Bus

RS232C

CAMAC

VME

主な用途

ビーム

低レベル rf
ビームモニタモジュレータ高いタイミング信号が必要になった。
表 12: タイミング信号の伝送と発生

そこで、入射器全体にクロック信号を分配し 、クロッ
クを計数することにより遅延信号を生成することにした。加速用マイクロ波のド ライブラインには 2856MHz

7.2.4が使われているが、遅延信号を作るためには不都合なた
め、SHB2 に使用される 571MHz をクロックとして分

遅延タイミング信号の発生

副トリガステーションでは、受け取った 50Hz タイミ

配することにした。

ング 信号を起点にして、571MHz クロックを計数する
ことにより各機器に必要な遅延信号が生成される。従って、1.75ns を単位として遅延が選べることになる。遅延計数には Timing-Delay-4 (TD4) と呼ぶ ECL カウンタを内蔵したモジュールを使用しているが 、各ステーションの都合により、VME 、CAMAC 、RS232C が制御接続に用いられ 、それぞれ TD4V 、TD4 、TD4R と呼ばれている。カウンタは 16bit なので 、最大 114 μ s の遅延を行うことができる。24
機器毎に必要なタイミングが異なるため、それぞれ別に TD4 を設置してあり、現在は合計約 150 台になっている。それらの TD4（ 及び loop3 遅延モジュール ）は、そ
れぞれに対応したド ライバソフトウェアを通して、階層的な制御ソフトウェアで他の加速器機器と同様に統一的に管理され 、運転ソフトウェアや加速器のオペレータか

図 17: 50Hz パルス信号（上）、及び 571MHz クロックと 50Hz

らはハードウェアの違いを認識する必要はない [57, 47] 。

信号が重畳された伝送信号（ 下）7.2.5
50Hz の各パルスについてタイミンング信号が必要に

パルスマイクロ波用タイミング信号

マイクロ波用タイミング 信号としては 、低レベルマなるわけだが 、571MHz クロックと 50Hz のタイミング
信号を別々に伝送すると、信号伝播の遅れの差により、クロックのずれが懸念され る。それを避けるため 、ク

イクロ波生成用のタイミングと、大電力クライストロン
モジュレータの高圧パルスタイミングがある。
低レベルマイクロ波については 、各 1 次副ト リガス

ロックとタイミング信号を重畳させる機構を主トリガス

テーションにおいて 、パルスエンベロープと SLED のテーションに用意し 、1 本の同軸ケーブルで伝送するこ

位相反転タイミングが作られ、サブブースタクライストとにした（ 図 17 ）。その信号は同軸ケーブルから方向性結合器によって 1 次的な副トリガステーション 9 ヶ所、及び KEKB 入射用の電子銃ステーション (A1 電子銃)

20

24 一部の 2 次副トリガステーションでは、loop3 という入射器独自の通信規格に接続された非同期の遅延モジュールが使われているが 、
2002 年夏に TD4V に置き換わる。

Server

Client
Opt-network
X-terminals
Unix

poplarplum
lycheefor operation

touch-terminals
MS-DOS
almondPC Console system
Window NT

し 、またはそれより少ない 1Hz や 5Hz など 4 種類を生Sub systems
Opt-networkorangefor develop

Shell script
Unix

ABC Sec Sub-control
CAMAC TD4
1 system

成して 、対より線によって 1 次副ト リガ ステーションに分配されている。副トリガステーション側の TD4 に2 Sec Sub-control
VME loop3
1 system

は、50Hz タイミング信号にそれぞれ必要なゲートをか

1 5 Sec Sub-control
VME TD4V
4 systems

けて、遅延信号が供給される。例えば 、ビーム位置モニ
タのデータ収集用には観測モードによって、1Hz や 5Hz

A 5 Sub-booster
CAMAC TD4
8 systemsなどの信号が配られる。
信号は、19 のビームモニタステーション、2 つのワイ
ヤモニタステーション 4 つのストリークカメラステー

図 18: タイミング関連の制御ソフトウェアの構成、他の入射ションに送られている。これらのステーションからは、器の機器の制御と同様、複数の制御機器の違いをサーバソフ
トウェアで隠し 、アプリケーションソフトウェアからは、信号遅延時間、待機モード 選択、ビーム繰り返し 、などについて均一な制御サービ スを提供している。

ビーム位置モニタ 90 台、ランダムシャッタカメラ 10 台、
ワイヤスキャナ 14 台などへタイミング信号が接続されている。また、入射用のセプタム、キッカーのトリガもこの仕組みで用意されている。

ロンに供給される。そこで生成されたパルスマイクロ波
がそのセクタ内の大電力クライストロンに送られるこ7.3とになる。この SLED の位相反転タイミングは 、大電システムの性能と今後

図 19 はストリークカメラで観測したビームのバンチ

力マイクロ波の安定度に直接影響するが 、上に述べたよ構造である。ビームの観測幅約 9ps はシミュレーション

うな機構により十分な精度を持って供給されている。

とよく一致する。このことは、タイミングシステムからクライストロンモジュレータの高圧タイミングにつ供給されているビームタイミングとスト リークカメラ

いては 、各 2 次副ト リガステーションにおいて 、クラのタイミング、及び加速マイクロ波の間のジッタが 9ps

イストロン毎に TD4V が用意され 、個々に遅延を決めよりも十分小さいということを意味しており、タイミン

た上で信号がモジュレータられるようになっている。

グシステムの精度の高さを表している。

大電力クライストロンは現在 59 台設置されているが、通常は数台が障害時の交換用として待機（ スタンバイ）
モードに置かれ、運転には使用しない。これらのスタン
バイクライストロンもすぐに使用できるように、ビームとはずらしたタイミングで仮の運転状態にしておく必要がある。そのために、低レベルマイクロ波のエンベロー
プについては 57 μ s（ TD4 の遅延レンジの半分）離れた 2 つのパルスを供給し 、高圧タイミングでそのいずれかを選択する。その選択の組合せは、ビーム種別によって異なる。入射器のビ ーム運転モード は大きくわけて

KEKB e 、KEKB e+ 、PF e 、PF-AR e 、の 4 つがあ
るが 、それらのビームモード を変更したときにソフト

図 19: ストリークカメラによるビームバンチ構造の測定でウェアにより待機モード のクライストロンを切り替えて10nC ビームの幅が約 9ps に見えているいる [52] 。

7.2.6

2001 年から、入射効率を増倍させるために、ひとつビームモニタ用タイミング信号の rf パルス内で 2 つのビームバンチを加速する、いわビームモニタ用のタイミング信号も上と同様の仕組

ゆる 2 バンチ加速がしばしば 行われている [58] 。このみを用いて 、各 1 次副ト リガステーションにおいて発モードでは、ウェーク場の影響などを逃げながら、96ns

生させている。しかし 、ビームの繰り返しは 50Hz より離れた 2 つのバンチを同等に加速するために、2 つのバも低いこともあるので、50Hz タイミング信号の直前にンチのビーム特性をよく合致させる必要がある。入射器

遅いゲート信号を送って、ビームを区別できるようにし内には特に速いキッカーなどは設置されているわけではている。

なく、SLED の位相反転タイミングなどを調整して、エゲート信号は主トリガステーションで、ビーム繰り返

ネルギーアナライザやエミッタンスモニタなどで測定し21

たビーム特性を合致させることになる。現在のところ、
電子銃タイミング、バンチャ rf タイミング、そして各セ

8.1

ビームオプティクス

現在の入射器においてもまだまだ解決すべき問題はクタの SLED 位相反転タイミングを調整することによ多く、特に大電流であることによるウェーク場の効果もり、2 バンチとも効率よく入射できることがわかっていあって、ビームオプティクスはなかなかモデルと一致しる [59] 。

ない部分も多い。しかし 、加速勾配や磁場強度に使われこのようにタイミングシステムは順調に動作している較正係数など の誤差の積み重ねも影響している可能

るが 、いくつか障害もあった。まず、メーカーから提供性も否定できない。

を受けた CAMAC ド ライバソフトウェアの不具合が解

これらの誤差を押さえ込むために 、入射器の部分ご消せず、制御が不能になることがあった。これに対してとにビームを使った評価を今まで以上に進める必要があ

は、上位のソフトウェアを工夫することにより障害を避ると思われる。

けることに成功している [57] 。具体的には、一般に入射器内の機器の制御サーバソフトウェアでは冗長な複数のサーバが同等な働きをしているが、タイミング関連のサーバについては 、CAMAC 部分についてだけ独立な

8.2

他の制御システムとの協調

8.2.1

EPICS 環境の利用

さまざ まな加速器制御のための機構が実装されてき

1 つのサーバに仕事を集中させることにしている。これによって、障害はなくなっているが 、CAMAC ド ライバ

たが、特に蓄積情報などの高速処理についてはまだまだソフトウェアの不具合が解消されれば 、元の対称性のよ要求が多い。このような分野については、他の加速器にい構成に戻したいと考えている。

おいてもいくつかの実装が進んでおり特に EPICS のコ
ミュニティにおいて協力して環境を作ろうとする動きがまた、TD4/TD4V のモジュール個体によって、約 2 週

ある [60, 61] 。

間に 1 回約 200ms の間出力が停止することが見つかった。KEKB のコミッショニング当初はこのことに気がつ

そのような状況をふまえて、EPICS について考えるかず、また、頻度が低いためなかなか理解が進まなかっと、入射器の制御システムも徐々に EPICS の利用を増たが 、モジュール内の 2 ヶ所のコンパレータの不具合

やしていく必要がある。それを補強する要因は他にもであることを突き止められ 、2002 年夏には全て交換がある。

完了する予定となっている。
システムの安定度が高まって来たので、今後をそれを維持するために監視システムの充実を検討している。オ
シロスコープによる波形とタイミングの監視、及び時間
デ ィジタル変換器 (TDC) による各タイミングの監視の組み合わせとなる。ハード ウェアは既に一部が設置されていて人手による監視は行っているが 、常時監視を行うためにソフトウェアの開発を進めているところである。
第 8 節に書くような今後の改造についても検討しているが、現在のところ大きな変更は必要ないものと思っている。

8

まとめと今後入射器の制御システムはこれまで述べてきたように、入射器の運転に欠くことのできないものになっている。

 入射効率などの改善を目指して、現在以上に KEKBとの間で密に情報を交換する必要が高くなる可能性がある。
 すでに Channel Access Server によって入射器の重要なパラメータ 2000 あまりが EPICS 環境にも提供されている [15, 62] 。
 入射器の制御でキャッシュ情報などの非同期の情報交換の仕組みが強化され 、Channel Access Server の構築がより容易になっている。
 さらに多くのパラメータを EPICS 環境に公開すれ
ば 、アプリケーションソフトウェアからは入射器の制御システムは EPICS に見えるようになる。
 すでに入射器内でもワイヤスキャナは EPICS によって運用されている。
 入射器に既存のコントローラの EPICS ド ライバが他のプロジェクトのために開発されている [63] 。

しかし 、加速器自体の要求仕様も変わってきており、最このように制御システムの最上位のアプリケーション

近では連続入射や 2 バンチ入射のための対応が行われてソフトウェアと下位層の装置コントローラのソフトウェいる [59] 。また、1993 年の制御システムの更新、1997

アは部分的に EPICS に移行することが可能となってい年からの KEKB 入射のためのコミッショニングを経て、 る。これを進めることで、EPICS コミュニティで開発さ制御システムも機能拡張が必要な時期に来ている。

れたアプリケーションソフトウェアがそのまま利用でき22

る。当面、このような仕組みによって、蓄積情報の処理

うな高速のビームフィードバックが重要になると思われの高速化を期待している。

る。もしダンピング リングが導入された場合には 、大電流のビームの入射、出射のために、50Hz のフィード

入射器の場合は KEKB リング（と PF-AR リング ）がEPICS を採用しているために EPICS の方向性を当面目指す、という意味合いが強いが 、第 2 節でも述べたようバック動作も必要になると思われる。

に、今後は技術や成果の共有が重要になるということをシステムは、上流から下流に向かって干渉するので、そ念頭におく必要がある。

の相互作用を正し く評価しなくてはならない。そのた

8.2.2

このような高速のエネルギー、軌道のフィードバック

め、入射器全体のビームフィードバックシステムをビー

CORBA の利用

ム繰り返しの 50Hz で同期して動作させる必要がある

さらにその後の制御システムの協力体制がどのように[64] 。

なるかわからないが 、下位層は EPICS でも十分であっこのためには 、50Hz で動作する低レベル rf システ

たとしても、少くとも最上位については、次のような項

ム、キッカー、データ収集システムなどを用意する必要

目の検討が必要である。

がある。タイミングシステムは現在のものでもおそらく

 より誤りの少いソフトウェア開発を進めるために、
オブジェクト指向のプ ログラミングなど の支援が受けやすい環境。
 制御システム以外との密な情報交換のために 、より一般的な情報技術が利用できる環境。
 計算機プラットフォームなどに依存しない Java な
どの環境。

対応できると思われる。
そのようなシステムは SuperKEKB だけでなく、現在の入射器にも有効であると思われるので、その試験も始まっている。可能であれば 、軌道やエネルギーだけでな
く、エミッタンスやエネルギー幅の安定化も最終的な実験の効率には寄与が大きいと思われ、検討しているとこ
ろである。

8.3.2

これらを考えて、将来の加速器の制御システムの上間欠ビーム測定位層には、CORBA の利用が進むと考えられる。実際い

現在は、項目によって一日から一週間に一度、入射のくつかの加速器において CORBA の利用が検討されて無い時間帯に、rf のフェージングや、ビームオプティク

おり、入射器においてもウェブブラウザ経由の情報提供

スの再マッチングなどといった調整作業を行って、入射に利用されている [16] 。これが第 2 節に書いたような器の長期安定性を維持している。しかし 、SuperKEKB

Fad に過ぎないかど うかはまだわからないが、少くとも においては連続入射が行われるため、このような作業の現在のところ注目すべき技術であることは確かである。 時間が確保できなくなる。
そこで現在検討されているのは 、ビームパルスのう8.3 SuperKEKB に向けて
ち一部だけ、例えば 、1 秒に 1 パルスだけを選び測定や調整に使用する方法である。そのように選ばれたビーム

KEK の電子入射器の将来計画として期待されているのが 、現在の KEKB のルミノシティを 10 倍引き上げ

パルスはリングに入射されないように 、ビームトラン

る、SuperKEKB 計画である。その計画では現在以上にスポートの最後でビームダンプにけり出す必要がある。

入射器の役割が重要になる。制御システムとしても新しパルスを区別して加速器を多重に運転することになるい装置に対応するなどの KEKB の増強時に経験したもので、パルスモジュレーションとか仮想加速器と呼ぶこのと同様の機能拡張の他に、いくつか検討しておくことともできる。
このような測定のためにも前項で上げた高速同期処がある。

理が使われ 、また、調整の対象となる装置は 50Hz で動8.3.1

高速同期処理作する必要がある。連続入射が現在の KEKB でも有効なので、このような間欠測定システムも早くから導入で現在の 入射器では 、主にビ ームポジション モニタ

きた方が好ましい。

(BPM) の読み出しシステムの制限から 、ビームフィー
ドバックなどは一秒に一回しか動作できない [59] 。しか8.4

し 、試験的なビームの安定度の評価からは、50Hz まで
重要かど うかはわからないものの、10Hz 付近に変動要

終わりに加速器の制御システムは、加速器内の装置、ビーム物因があることが見つかっている。入射器の安定度を高め

理、ビーム運転など 、全ての要素と関わりを持っているるためには、より長期の変動への対策とともに、このよために、今後高度になる加速器ではさらに重要性が高ま23

et alると思われる。また最近、SASE FEL 、ERL 、リニアコ[16] N. Kamikubota., “Development of a CORBA Toolkit
and its Evaluation”, Proc. ICALEPCS97, Beijing, China,
1997, p.351.

ライダ、大電流加速器、医療用加速器など 、線形加速器が話題になることが多い。そういう意味で線形加速器のet al., “Microwave Control and Measurement[17] K. Furukawa
System at the KEKB Linac”, Proc. ICALEPCS97, Beijing,
China, 1997, p.146.

制御システムについては、まだまだ解決しなくてはならないことが多く現れると思われる。加速器の要求仕様

et alを見失わず、ひとつひとつ問題を解決できるような制御., “Introduction of Modern Subsys[18] N. Kamikubota
tems at the KEK Injector-Linac”, Proc. ICALEPCS2001,
San Jose, USA., 2001, p.328.

システムを構築して、要求に答えていきたいと考えて
いる。

et al

., “MMI Object Analysis and the Distributed[19] I. Abe
Components for a New Console in the KEK e-/e+ Linac”,
Proc. ICALEPCS97, Beijing, China, 1997, p.519.

なお、KEK の電子入射器に関連するレポートは一部ではあるがウェブに集めるようにしている。参考にされたい [65] 。

[20] K. Nakahara, “Control System for the KEK Electron Linac”,
OHO’85, Tsukuba, 1985.

et al

参考文献

., “New Control System for the KEK[21] N. Kamikubota
Linac”, Proc. Linac Meeting in Japan, Tsukuba, 1993,
p351.

[1] A. Enomoto, “Upgrade to the 8-GeV Electron Linac for
KEKB”, Proc. LINAC96, Geneva, Switzerland, 1996, p.633.

., “New Control System for the KEK[22] N. Kamikubota
Linac”, Proc. LINAC94, Tsukuba, Japan, 1994, p.822.

[2] K. Furukawa., “Towards Reliable Acceleration ofHigh-Energy and High-Intensity Electron Beams”, Proc.
LINAC2000, Monterey, USA., 2000, p.630.

., “Improvements to Realize a Higher[23] N. Kamikubota
Reliability of the KEK Linac Control System”, Proc.
ICALEPCS95, Chicago, USA., 1995, p.1052.

., “Present Status and Beam-Stability Issues[3] T. Suwadaof the KEKB Injector Linac”, Proc. PAC2001, Chicago,USA., 2001, p.4083.

., “Techniques to Improve Reliability[24] N. Kamikubotaof the KEK-Linac Control System” Proc. Linac Meeting inJapan, Osaka, 1995, p209.

., “Control System for the Photon Fac[4] K. Nakahara
tory 2.5-GeV Electron Linac”, Nucl. Instrum. Meth. A
251(1986)327.

., “Evolution of the KEK Linac Con[25] N. Kamikubota
trol System by Introducing New Subsystems” Proc. Linac
Meeting in Japan, Tsukuba, 2001, p273.

[5] R. Humphrey, “Lessons from the SLC for Future LC Control Systems”, Proc. ICALEPCS91, Tsukuba, Japan, 1991,
p.14.

., “An Operator Console System of the[26] K. Nakahara
Photon Factory Injector Linac”, Nucl. Instrum. Meth. A
293(1990)446.

[6] Proc. ICALEPCS91, Tsukuba, Japan,
ICALEPCS93, Berlin, Germany, 1993.

., “PC-based Control System using ActiveX in[27] I. Abe
the KEK e-/e+ Linac”, Proc. PCaPAC99, Tsukuba, 1999,
KEK-Proceedings 98-10.

et al

et al

et al

et al

et al

et al

et al

et al

et al

et al

1991. Proc.

., “Recent Progress in the Control System[7] K. Furukawa/ + Linac”, Nucl. Instrum. Meth. A
for KEK 2.5-GeV
293(1990)16.

e e

et al

., “Introducing PCs to Unix-based con[28] N. Kamikubota
trol systems”, Proc. PCaPAC2000, Hamburg, 2000.

et al., “Upgrade Plan for the Control Systeme /e+ Linac”, Proc. ICALEPCS91, Tsukuba,[8] K. Furukawaof the KEK
1991, p.89.

et al

et al

., “Database system in the KEK Linac PC[29] M. Tanaka
based Control”, Proc. PCaPAC99, Tsukuba, 1999, KEKProceedings 98-10.

[9] N. Kamikubota., “New Control System with VME and/ + Linac”, Nucl. Instrum.
Workstations for the KEK
Meth. A 352(1994)131.

et al

e e

., “PC as a touch-terminal controller”,[30] N. Kamikubota
Proc. PCaPAC99, Tsukuba, 1999, KEK-Proceedings 98-10.

et al

et al

[10] L. Dalesio., “The Experimental Physics and Industrial
Control System Architecture: Past, Present, and Future”,
Nucl. Instrum. Meth. A 352(1994)179.

., “Renewal of Magnet Controller for[31] A. Shirakawa
e+/e- Linac”, Proc. Engineering and Technology in Basic
Research, Tsukuba, 1999, KEK-Proceedings 99-16.

., “Present status of the KEKB control sys[11] T. Katohtem”, Proc. ICALEPCS97, Beijing, China, 1997, p.15.

., “Construction of Device Management[32] A. Shirakawa
Program for Vacuum Control System”, Proc. Linac Meetingin Japan, Sendai, 1997, p213.

et al

et al

et al

[12] J. Chen., “CDEV: An Object-Oriented Class Library for Developing Device Control Applications”, Proc.
ICALEPCS95, Chicago, 1995, p.97.

et al., “Data Acquisition of Beam[33] N. Kamikubota
Position Monitors for the KEKB Injector-Linac”, Proc.
ICALEPCS99, Trieste, Italy, 1999, p.217.

[13] P. Duval, “The Use of PCs in Controlling DESY Accelerators”, Proc. ICALEPCS97, Beijing, China, 1997, p.162.

et al., “Stripline-type Beam-position-monitor[34] T. Suwada
System for Single-bunch electron/positron Beams”, Nucl.
Instrum. Meth. A 440(2000)307.

<URL:http://acc-physics.kek.jp/SAD/sad.html>[15] K. Furukawa et al., “Integration Feasibility of the Existing

[14]

et al

., “RF Monitoring System in the Injector[35] H. Katagiri
Linac”, Proc. ICALEPCS99, Trieste, Italy, 1999, p.69.

Linac Control System and Ring EPICS System at KEKB”,
Proc. ICALEPCS95, Chicago, USA., 1995, p.863.

24

et alet al[56] E. Kikutani., “The KEKB Bucket Selection System- Recent Progress and the Plan in the Near Future”, Proc.
APAC2001, Beijing, China, 2001, p.669.

[36] N. Kamikubota., “Tool for Device Histories at the
KEK Linac”, Proc. LINAC96, Geneva, 1996, p.800.

et al., “Device Histories at the KEK[37] N. Kamikubota
Injector-Linac”, Proc. Linac Meeting in Japan, Sendai,
1997, p204.

et al., “Timing System Software for the KEK[57] S. Kusano
Injector Linac”, to be published in Proc. Linac Meeting inJapan, Kyoto, 2002.

et al., “Presentation of Klystron History[38] N. Kamikubota
and Statistics by World-Wide-Web”, Proc. Linac Meetingin Japan, Himeji, 2000, p252.

[58] Y. Ogawa et al., “Two-Bunch Operation of the KEKB
Linac for Doubling the Positron Injection Rate to the KEKB
Ring”, Proc. APAC2001, Beijing, China, 2001, p.112.

et al., “Accelerator Archive Databases as[39] N. Kamikubota
Distributed CORBA Objects”, Japan Physical Society Annual Meeting, Okinawa, 2001.

et al., “Beam Feedback Systems And BPM[59] K. Furukawa
Read-Out System for the Two-Bunch Acceleration at the
KEKB Linac”, Proc. ICALEPCS2001, San Jose, USA.,
2001, p.266.

et al., “Study of Sharable Applications Us[40] S. Kusano
ing Java and CORBA”, Proc. ICALEPCS99, Trieste, 1999,
p.535.

et al

et al

., “Signal Archiving and Retrieval: Es[60] R. Müller
sential Long Term Performance Tuning Tool”, Proc.
ICALEPCS2001, San Jose, USA., 2001, p.662.

et al., “Overview of the Experimental[61] K.U. Kasemir
Physics and Industrial Control System Channel Archiver”,
Proc. ICALEPCS2001, San Jose, USA., 2001, p.526.

., “Network Communication Libraries[41] N. Kamikubota
for the Next Control System of the KEK e-/e+ Linac”, Proc.
ICALEPCS91, Tsukuba, 1991, p.318.

et al., “Software module for Network[42] N. Kamikubota
Servers”, KEK-Linac Internal Report PFINJ-MC-32, 1992.

et al[62] M. Kaji and K. Furukawa, “Operation of KEKB Linac andRing with EPICS”, Proc. Linac Meeting in Japan, Tokyo,
1996, p207.

et al., “Implementation of the EPICS[63] K. Furukawa
Device Support for Network-Based Controllers”, Proc.
ICALEPCS2001, San Jose, USA., 2001, p.197.

., “Control Transactions of the KEK[43] N. Kamikubota
Injector-linac Control System and the KEKB Commissioning”, Proc. Linac Meeting in Japan, Sapporo, 1999, p119.

et al., “Growth of Control Transactions of[44] N. Kamikubota
the KEK Linac during the KEKB Commissioning”, Proc.
APAC’02, Beijing, 2001.

et al., “Beam-Based Feedback Simulations[64] L. Hendrickson
for the NLC Linac”, Proc. LINAC2000, Monterey, USA.,
2000, p.74.

et al., “Improvement of the KEK Linac Con[45] K. Furukawa
trol System towards KEKB”, Proc. Linac Meeting in Japan,
Tokyo, 1996, p210.

[65]

et al

., “Reliable Controls with Diskless VME[46] T. Obata
Computers at KEK Linac”, Proc. Linac Meeting in Japan,
Himeji, 2000, p.255.

et al., “Accelerator Controls in KEKB Linac[47] K. Furukawa
Commissioning”, Proc. ICALEPCS99, Trieste, Italy, 1999,
p.98.

<URL:http://www.tcl.tk/>[49] D.C. Carey et al., “Third-Order TRANSPORT with MAD[48]

Input, A Computer Program for Designing Charged Particle
Beam Transport Systems”, FERMILAB-Pub-98/310, 1998.

et al., “Control System for a Bunch Profile[50] K. Furukawa
Monitor at the KEK e+/e- Linac”, Proc. LINAC94, Tsukuba,
Japan, 1994, p.819.

et al., “Energy Feedback Systems at the[51] K. Furukawa
KEKB Injector Linac”, Proc. ICALEPCS99, Trieste, Italy,
1999, p.248.

et al., “Beam Switching and Beam Feedback[52] K. Furukawa
Systems at KEKB Linac”, Proc. LINAC2000, Monterey,USA., 2000, p.633.

et al., “Commissioning of the KEKB 8-GeV[53] A. Enomoto,e- / 3.5-GeV e+ Injector Linac”, Proc. PAC99, Stockholm,
Sweden, 1998, p.713.
[54] Y. Ogawa and Linac commissioning group, “Commissioning Status of the KEKB Linac”, Proc. PAC99, New York,
USA., 1999, p.2984.

et al., “Low-Power rf Systems for the KEKB[55] H. Hanaki
Injector Linac”, Proc. APAC98, Tsukuba, 1998, p.139.

25<URL:http://www-linac.kek.jp/linac/>

目次
1

はじめに

1

2

加速器の制御

1

3

4

5

6

7

8

2.1

加速器の制御の歩み

2.2

制御システムの目的と構成: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :1
2

KEK 電子入射器の制御の概要

33.1

入射器の制御の設計

33.2

入射器の制御の全体構成

3.3

装置コントローラ

3.4: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :4: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :4中央制御計算機とネットワーク : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :4

ハード ウェア構成

5

4.1

歴史的経緯

4.2

設計方針と全体構成

4.3

構成要素

4.4

制御ネットワーク4.5

履歴（ Archive ）システム: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :5: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :5: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :5: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :ソフト ウェア構成

7
8
9

5.1

歴史的経緯

5.2

設計方針と全体構成

5.3

制御ソフトウェアの詳細: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :99: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :9: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

12

5.4

Example(D-out)

5.5

制御メッセージの速度

5.6

運転中の機器サーバの負荷 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :運転ソフト ウェアとビーム制御

14

14

6.1

アプリケーションソフトウェア : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14

6.2

情報の交換

6.3

オペレータインタフェース

6.4

運転用アプ リケーション

6.5

KEKB 入射器の安定化

6.6

ビーム運転ソフトウェアの効果 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :15: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :15: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :16: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :16

タイミングシステム

19

7.1

入射器のタイミングシステム

7.2

タイミングシステムの構成

7.3

システムの性能と今後 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :19: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :19

まとめと今後22

8.1

ビームオプティクス

8.2

他の制御システムとの協調

8.3

SuperKEKB に向けて

8.4

終わりに

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :22: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :22: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :23: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

23

26

参考文献

24

27