ページトップへ戻る

Volume 09, No.1 Pages 46 - 49

4. 研究会等報告/WORKSHOP AND COMMITTEE REPORT

ICALEPCS 2003会議報告
Report on ICALEPCS 2003

田中 良太郎 TANAKA Ryotaro

(財)高輝度光科学研究センター 加速器部門 Accelerator Division, JASRI

Download PDF (25.14 KB)

はじめに
 加速器、大規模実験の制御システムについての国際会議であるICALEPCSは2年に一回開催される会議で、今年は順番からアジア地区での開催になった。今回の会議は10月13日から17日まで韓国慶州市で開催された。慶州といえばその昔は新羅の都であったところで、日本には歴史的に馴染みがある名前だ。近くには放射光施設PAL、POSTECHといった大学があり、会場は普門湖の辺に建つHotel Hiltonであった。ICALEPCSがヨーロッパや、米国などで行われるときは長旅の疲れと時差を克服しながら参加しているが、今回は韓国ということで時差もなく初日からシャキッとした頭で会議を迎えた。
 さて、参加者300人を越えたICALEPCS 2003では制御分野を網羅すべく12のセッションがあり、74件の口頭講演はすべてプレナリーで行われた。つまり全セッションを聞くことができた。おかげで朝は8時半から夕方6時過ぎまで口頭講演でぎっしり詰まった構成になっている。SPring-8からは3つの口頭講演と、3つのポスター発表を行い、筆者が会議の最終日にTechnical Summary講演を行った。
 制御の会議らしく全ての口頭発表はPCで行われた。人によっては動画も織り込むなどしてPower Point全盛といったところだ。発表者は別室に用意されたPCで、自分の発表が正しく表示できるかファイルを事前にチェックできるようになっており、問題なければ発表会場の担当者に連絡して、備え付けのPCで講演を行う。おかげで、PCのトラブル等で発表時間をロスすることは無くなった。また、発表したファイルが主催者のPCに残ることから、実際の発表原稿がPDF型式に変換されて、Web上で公開されている。誰でも見られるので、この情報は会議に出た人にも、出られなかった人にも有用だと思う。今後の参考にしたい。紙面の関係で全てのセッションの報告はできないので、いくつかまとめて報告したい。会議のプログラム、発表原稿など詳しくは、http://icalepcs2003.postech.ac.kr/で。


Status report
 初日の朝はいつも決まってStatus reportから始まる。いつにも増して核融合関連の発表が多かったように感じた。トップはJ-PARCの発表。高エネ研と原研の共同チームで建設が進められており、進捗の報告があった。SPring-8は理研と原研の共同チームだった。サイトの建設現場から「遺跡」が発見されるとスケジュールが遅れ、発掘作業費用も建設者負担となり予想外の要因となるそうだ。プロジェクトが遅れないためには「遺跡が出ないように」と祈ることも必要か。8件の講演のうち3件が核融合関連だった(NIF1件、ITER2件)。核融合炉の制御系はさぞかし加速器とは違うだろうなと思いそうだが、結構、加速器の制御にも参考になる。オブジェクト指向、CORBAミドルウェア、Javaプログラミング、共有メモリネットワークなど馴染みのある話が出てくる。高速に変化するプラズマの電流、位置、形状等を実時間制御する必要があり、実時間制御性を意識した設計になっている。レーザー核融合研のNIFでは300のプロセッサ、6万点の制御点数にわたって、多数の診断プロセス間の情報共有、実時間制御、自動制御を実現していく必要があるとのこと。色々と参考になりそうである。高エネルギー検出器ではCERN/LHCからの報告が2件あった。大型の検出器の建設状況の報告はさることながら、2000人を越える巨大化した共同研究者(collaborator)をどの様に取りまとめて、効率的なシステム開発を行うことができるのか方法論に重点が置かれていた。


Project management
 Status reportに加えてこのセッションでも、マネージメントに関して有用な話を聞くことができた。制御の会議でプロジェクト管理を議論しているのは、大規模な装置の制御システムを構築するには、人・グループを制御し、情報の共有・配布を制御し、効率化を達成しつつ、全体を協調進行させることで、実用になる制御システムがオン・スケジュールで、できあがってくるからに他ならない。これらの人、機材が世界中に分散し、所属機関も異なっている場合は、その困難さは想像に難くない。
 これを実践に移したNIF、SNS、ALICE/LHC、ALMAの話は、それゆえ実に興味深い。品質管理手法と明確に定義された試験手法の実践ではNIFに脱帽。NIFでは「品質確認試験チームが、計量手法に則って開発者立ち会いの元で試験を行う」、「試験方法と計量的結果は品質管理責任者が精査する」。「何らかの変更が必要な場合は、変更管理委員会が妥当かどうかの可否を裁定し」、「最後に各部担当責任者が変更を行うかどうかを最終決定する」といった具合に実にシステマティックに進行している。ソフトウェアのコードを1行変更する場合、ドキュメント改訂も含めて1日で反映できるとの回答だった。6研究所の共同プロジェクトであるSNSは、前回のサンノゼの発表に引き続いて、その後2年間の経験談を発表していた。この間に学んだことは“Inter laboratory project is still difficult.”だそうだ。とはいっても手慣れてきた面もあり、作業を構造化して構成要素に分けていく方法のWBS(Work Breakdown Structure)、密なる電話連絡などでプロジェクト進行が上手になった面もある。電話連絡は古典的だが有効らしく、直接のコミュニケーションに勝るもの無しということか。
 CERN LHC実験の4つの巨大検出器の開発、最近日本も参加したチリのALMA電波望遠鏡プロジェクトなどの国際共同プロジェクトのマネージメントもあった。アーキテクチャやフレームワークといった基本構造の開発に責任を持つチーム(例えばCERNではJCOPチーム)が「大枠」を決め、「全体調整」を行う。傘下のグループは「各部分を分担」して作成する、あるいは「各グループ特有の部分を作成」するなどの「分業型式」で進行している。それでも大変だそうだが、上位設計はTop-downで、各部分はBottom-upでプロトタイピング開発という開発方法論は定着した感がある。


Process tuning & Feed-back
 このセッションではDSPを用いたElettra+SNSのバンチ・バイ・バンチF/Bの発表があった。アルゴリズムの説明では、ダンピングが利く様子をシミュレーションした動画表現は、分かりやすく視覚によく訴えていた。結果も満足すべきでF/Bによるダンピングの成果が得られていた。BESSY-IIでは電子ビーム安定化のためにありとあらゆるビーム軌道補正を行って、極限まで安定化を突き詰めていくこと(SPring-8もそうしている)が報告された。ここでも核融合関連の発表が2件有り、プラズマ制御の方法論とシミュレーション手法の発表があったが、ここではこれ以上は述べない。


Upgrade and Re-engineering
 毎回、多くの発表が寄せられるのがこのセッションである。古くなった制御システムを更新したい、でも加速器は実稼働中であり長い停止期間もとれない、もちろん失敗は許されない、などが悩みどころとなる。何が問題で、どの様に更新作業を立案し、どの様な技術を導入したかがポイントになる。Fermilabは20年前のVAXベース、CERN SPSも20年前のものとなってしまったCAMAC、NODALシステムの更新にとりかかる。Fermilabは全体を一気に変えるのではなく「piecewise」に更新する方法をとる。ソフトウェア変更ではVMSのコードをJavaで書き換え、Web技術(Tomcat)を利用する。後で述べるが、この会議ではJavaとWeb技術が大流行であった。CERN SPSは「Function Oriented」な現状から「Equipment Oriented Hardware」にする、「インターフェイスを共通化する」、「メンテナンスを楽にしたい」、「信頼性を上げたい」等Java(J2EE)、Oracle、VME+LynxOS、PLCベースで更新を目指す。10年を越えるESRFでもC/C++、RPC、Client/Server、X11/Motif、VME、OS9から、Compact PCI、Linux、Windows PC、C++&Java、Python、CORBAに置き替わって行く。SPring-8はJavaベースではないが、本筋はあくまでも機器制御性なので、Java化がこの点でどの様な制御上の利点があるのか今後見極めていかなければならない。
 古いと言えば、今や140以上の機関が採用しているEPICSも例外ではない。いずれ限界が来ることを見越して、EPICS 2010プロジェクトを立ち上げた。これは将来の制御ニーズを満たすためには、何が要求されるか要件定義を行うために、まずはEPICS使用者に意見とアイデアを求めることから出発している。このセッションではSPring-8線型加速器制御系の更新に関して増田が発表した。「限られた時間で、確実に実行し、実運用に移行させるための準備と手法」には会場の多くの人の共感を得ていた(うなずいている頭の数と動きで分かる)。


Front-end & Hardware & Safety
 ここではLHC用耐放射線デバイス試験、Beyond crateを実現するネットワーク接続型制御、J-PARCとDiamond放射光タイミング系、実時間制御系、安全性、LHCビームインターロック関連の報告、それに福井がロジック再構成可能なFPGA(DSP)デバイスを用いたSPring-8制御の報告と大端のVMEマルチマスターCPUでの実時間制御の報告があった。Safetyのセッションはこの会議で初めて設けられた項目だが、意外といっては失礼だが面白かった。中でもCERN/LHCでの7TeVの陽子ビームに関する安全性と耐放射線性の確立はこれほどまでに大変かと感心した。LHCトンネルを周回する7TeVの陽子ビームは500kgの銅を溶かす程のパワーを持っている。もし、ビームが制御性を失ってビームパイプにでも当たったらどうなるか?超伝導マグネットに達したらどうなるか?と思うとその損害は計り知れない。損害を防ぐには高信頼性のモニター系、監視系、ダンプキッカー系が必要であり、これらをPLCベースのpassive fault-tolerant redundantなHWと、active fail-safeなHW+SWでガッチリ守ることになる。それも同時不具合を避けるために、冗長なシステム間で共通技術を使用しないという念の入れようである。検出器の安全系でも自動制御で自律性を有するシステム設計になっている。また、制御系のエレクトロニクスに関しても中性子によるCMOS損傷の試験等に重点を置いて、PLC、VME、CANBusなどの耐放射線実験をPSI他で行っている。その結果、Flash memoryを使う、低電圧MOSFETを使う、三重の冗長性を確保するなど結果が出てきている。どうしても放射線の影響から逃げられない場合は、CPU、FPGAなどの最新デバイスの使用を諦めると言っていたのは本気なのだろうか?上手くいくことを祈るばかりだ。


Software engineeringとMiddleware/Componentware
 この記事を読んでいる多くの読者にとって、ミドルウェアはまだしも、オックスフォード英英辞典にも載っていない「Componentware(コンポーネントウェア)」という言葉は耳慣れないであろう。制御の世界でもそうだった、去年までは。少し説明すると、ハードウェア製品を効率よく製作するためには、全体をいくつかの機能的な部品に分割しておき、部品を流用することで種々の製品を作り上げていく。平たく言えばコンポーネントウェアとは、このようなアセンブリー的な方法をソフトウェアの世界でもやっていくことを意味している。ソフトウェアを流用可能な機能単位で部品に分解し(コンポーネント化)、これらの部品を再利用することでソフトウェア開発を進める方法を「コンポーネント指向ソフトウェア開発」と呼ぶ。オブジェクトからコンポーネントへのパラダイムシフトを目指すのは、生産性の向上はオブジェクト指向で達成できたものの、コードが思ったほどには再利用できないという現状を打開することからきている。部品の詳細を利用者が理解する必要がある「ホワイトボックス的」なソフトウェア開発から、「ブラックボックス的」な部品集合を再利用する開発手法にして生産性を上げることを目指す。これをJava/CORBAベースで実現したのが、LHC時代に対応したCERNの加速器Control Middleware(CMW)であり、J2EE(Java to Enterprise Edition)をベースに作成した、CERN/SPS CESARの新3-Tier構造ミドルウェアになっている。2006年のシステムインストレーションを目指して順調のようだ。“It is the only solution. No alternatives.”と言い切っていた。データ表現としてはXML型式を用いている。XMLのできが悪いと制御性が悪いと報告していた。ESRFでも「オブジェクト」から「コンポーネント」へのパラダイムシフトを感じたのか(推進したいのか)、“Java/CORBA is the best solution. More and more Java …(by A.Gotz)”とJava/CORBAベースへと移り変わる。でも、処理速度が必要なところにはC++を、と言っていたので適材適所を考えるべきなのだろう。様子を見る価値がありそうだ。


Internet technology & distributed knowledge
 Java大流行といったのはこの流れがWeb技術でも、もてはやされているからである。むしろこっちの方か。Webのサーバーサイド・アプリケーションはJava(J2EE)で作成し、データ形式はXMLを使う。サーバーエンジンにはApache/Tomcatを導入し、サーバーサイドでコンテンツの動的な作成を行うのが標準的なようだ。SPring-8でも収納部監視システムにはJavaベースでApache/Tomcatを導入している。Web技術はInter-laboratoryプロジェクトでは情報共有/公開の手段として強力であり、また必須の技術となっている。情報の共有/交換ではXML/XSL型式は便利なのかもしれない。これを今風のIT流に表現すれば、「B2B (Business-to-business)ソリューションの一形態になっている」と表現することになる。造語をすると、「L2L (Laboratory-to-laboratory)ソリューション」とでもいおうか。
 さて、情報公開と共有ではやはりDESYが開発したe-LogBookは便利だ。2年間使用した経験を報告していた。今ではHTMLベースではなく全てJavaベースになっている。データ表現にはXMLを使い、一元管理下において管理している。OracleへのアクセスはJDBCまたは自作のDOOCSでできる。認証にはApache/Tomcatを使う。今後はSOAPなどのWebサービスもできるようにするそうである。日本語のようなユニコードを入れられないか?という質問には、「特に制約はない」との回答であった。手書きのデータはスキャナーで取り込んでいるとのこと。SPring-8でも導入してはどうだろうか?便利そうではある。次世代のリニアコライダーのような国際共同プロジェクトでは必須の要素技術になるだろう。Global Accelerator Network(GAN)のような、次世代加速器の世界的共同研究の輪も既に動き出したことでもあるし。

 最後に、韓国は近かった。時差もないし、楽であった。風景も何となく播磨のそれに近い感じだ。食事は特に辛いものを除けば問題なし、それどころか、大いに楽しめる。今回のメンバーは大いに堪能したようだ(「ようだ」とあるのは、頻繁に役員会に呼び出された筆者はそれほど自由行動できず、「垂涎の焼き肉」には一度も一緒に行けなかったからだ。残念。)。PALは放射光施設であり、近くでもあり、さらなる交流を深めるのも良い事だと思う。




田中 良太郎 TANAKA  Ryotaro
(財)高輝度光科学研究センター 加速器部門
〒679-5198 兵庫県佐用郡三日月町光都1-1-1
TEL:0791-58-0868 FAX:0791-58-0850
e-mail:tanakar@spring8.or.jp



Print ISSN 1341-9668
[ - Vol.15 No.4(2010)]
Online ISSN 2187-4794