粒子加速器施設の作業員安全システムの導入

トーマス・ジェファーソン国立加速器施設 (JLab) は、米国エネルギー省科学局の国立研究所です。ここには、原子物理学の基礎研究を行うために用いる電子ビームを生成する連続電子ビーム加速器施設 (CEBAF) があります。最初から最後まで、電子は施設のレーストラック設計の周りを最大 5 周半移動し、最大 120 億電子ボルト (12 GeV) まで加速します。

施設で働くスタッフへのリスクを「合理的に達成可能な限り低く」 (ALARA) 抑えられるようにするため、ジェファーソン研究所の安全システムグループ (SSG) は、作業員安全システム (PSS) の設計、運用、保守を行っています。PSS は、瞬時に電離放射線に直接さらされることを防ぐといった、さまざまな安全機能を担っています。

PSS は、安全上の危険が存在する可能性のあるエリアへの立ち入りをスタッフが管理するのを支援します。たとえば、ビームが作動している間、加速器のトンネル システム内にはいくつかの重大な安全上の危険が存在します。これらには、電離放射線と非電離放射線、レーザー放射線、およびトンネルアークの周囲にビームを再循環させるために使用される電磁石上の露出した高電圧電気導体が含まれます (図 1)。最悪の場合、瞬時に電離放射線にさらされると、数分以内に致死量に達する可能性があります。PSS は、ビーム操作の前に作業員が加速器のトンネル システム領域から退去したことをスタッフが確認するのを支援し、ビームの運転が完了するまでスタッフが物理的にその領域に入れないようにします。

PSS は現在、すべてのソフトウェア機能を根本から書き直すことを含む大規模なアップグレードを実施中です。PSS のソフトウェアを開発するために、IEC 61131 から Function Block Diagramming (FBD) と呼ばれるグラフィカル言語を選択しました。

Simulink^® によるモデルベースデザインは、PSS ソフトウェアの構築に使用している実装や検証のワークフローで中心的な役割を果たします。PSS のすべての機能は、まず Simulink でモデル化され、次に Simulink Design Verifier™ によって生成されたテスト ケースを使用してシミュレートされます。この作業に Simulink を選んだのは、求めるグラフィカル機能をモデル化するのに必要な高速で、十分に信頼できる、成熟した手段を提供し、実装前に設計が論理的に正しいことを検証できるためです。さらに、Simulink Design Verifier を使用することで、他の要件の中でも特に、すべてのプログラム機能に対して 100% のテストカバレッジを達成し、設計が安全であることを実証できます。

機能テスト、算術エラー チェック (整数範囲違反など)、カバレッジ分析など、必要な設計、テスト、安全性ライフサイクル アクティビティをすべて単一の環境で完了できることは、大きな利点です。

スコープと複雑性の課題

PSSは、安全性インテグリティレベル 3 のリスクに対して、アクセス制御違反とビーム制御違反の2つの大きなカテゴリーを検出し、対応するように設計されています。これらは本質的に同じコインの裏表です。発生原因は異なるものの、どちらの違反も人とビームの間の隔離が失われる結果となります。アクセス制御違反中に、人が施設内の立ち入り禁止区域に入る場合、すべての危険は数秒以内に (つまり、人がトンネルの下層階に到達する前に) 停止されなければなりません。ビーム制御違反が発生すると、ビームがアクセス可能な領域に向かって誤って誘導されたり、アクセス可能な領域を遮断するビーム停止装置上に誤って誘導されたりする可能性があります。ビームの出力が非常に高いため (100 万ワット)、後者のシナリオでは、わずか数ミリ秒でビームをシャットダウンする必要があります。

PSS の設計と検証の課題は、システムの複雑さと規模によってさらに複雑になります。PSS は、施設の 9 つのセグメントに分散された 2,200 を超える I/O チャネル (センサーとアクチュエーターを含む) で構成されています。セグメントは連動したゲートとドアによって互いに分離されています。各セグメントの PSS は、Siemens^® 1500 シリーズの安全 PLC に基づく二重冗長化安全システムで構成されています。

システムには合計で 18 個の分散型安全 PLC と、データ交換に使用される 200 個の PLC 間通信チャネルが含まれています。クロック サイクルごとに、約 2,000 個のセンサーからのデータが読み取られ、光ファイバー ケーブルを介してメイン コントロール センターに送信され、処理されます。結果が計算されると、さまざまな警告およびシャットダウン デバイスを制御するために現場に送り返されます。このサイクル全体はわずか数ミリ秒で完了し、継続的に実行されます。PSS 内のコードの約 50% は、診断および自己監視の目的 (つまり、障害検出) に使用されます。

この規模の制御システムには、多大なエンジニアリング投資が必要になります。しかし、安全システムは、同じ機能を実装する際に非安全システムよりも 3 ～ 10 倍のコストがかかる可能性があります。FBD 言語を使用して Siemens の安全 PLC をターゲットにすると、Simulink PLC Coder™ を使用して Simulink モデルから直接 IEC 61131 構造化テキストを生成することができなくなります。代わりに、すべての Function ブロックはまず Simulink で設計および検証され、その後、TIA Portal (PLC の開発と展開に使用される Siemens 統合開発環境) の FBD 言語を使用して手動で再実装されました (図 2)。

従来のワークフローの拡張と改善

PSS の範囲と複雑さを考慮して、既存の開発ワークフローを最適化する方法を検討する必要がありました。従来のワークフローでは、Function ブロックの動作が Simulink で定義されたら、入力ベクトル (刺激) と出力ベクトル (目的) を含むテスト ケースを Simulink で定義する必要がありました。テスト ケースはSimulink Test™ を使用して実行され、テスト カバレッジはSimulink Coverage™ を使用して測定されます (図 3、ルート 1)。

このアプローチには 2 つの重要な問題があります。まず、すべての機能に対してテストケースを手動で生成する作業は、経験豊富なテストエンジニアにとっても非常に時間がかかります。第二に、テストがテスト対象の機能に対して 100% のカバレッジを達成しない場合、これが機能自体の設計エラーによるものか、またはテスト方法の欠陥によるものかを判断するのが非常に困難になる場合が多く、より多くのテストを定義して実行する必要があります。

これらの問題を解決するために、 Simulink Design Verifier を使用して、100% のカバレッジを達成するテスト ケース (形式手法を使用) を自動的に生成しました。これにより、テストケースを手動で定義する作業が不要になります。また、テスト対象の機能における設計エラーをどのように検出するかという問題も解決します。Simulink Design Verifier が100% のカバレッジを達成できない場合、関数自体の設計エラーの場所が強調表示されます。このワークフローは、従来の方法 (図 3、ルート 2a) に比べて大幅に改善されています。

Simulink Design Verifier を使用すると大きなメリットが得られますが、実行する新しいタスクも発生します。従来の方法では、テスト エンジニアは通常、テスト ケースの開発時に、必要な機能動作 (目標) を暗黙的にテスト ケースに設計します。テストに合格すれば、関数は正しく動作していると言えます。ただし、自動テスト ケース ジェネレーターを使用する場合、正式なアルゴリズムには、正しい論理動作と見なされるものについての知識がありません。このため、 Simulink Design Verifierによって生成されたテスト ケース (および対応する結果) の動作の正確性を確認する必要があります。つまり、生成されたテストをレビューして、関数が意図したとおりに動作していることを確認する必要があります。

これは、タイミング図を使用してテスト ケース (および予想される出力) を直接確認するか、テスト ケースをシミュレートしてモデル自体で時間ベースのシミュレーション結果を観察することによって実行できます。どちらのオプションも、関数に多数の入力と出力がある場合には特に、やや複雑でエラーが発生しやすくなります。このようなテストには、 Simulinkをインストールした経験豊富なテスト エンジニアが必要であり、レビューする関数が多い場合はレビューの見落としが発生しやすくなります。

私たちは、会議形式の環境でグループによる設計レビューを実施することに興味があったため、当社のソフトウェア機能の動作の精度を検証する動作検証チェックリストというコンセプトを開発しています。Simulink のテストケースを手順形式に変換する MATLAB^® スクリプトを作成して、従来のタイミング図よりも迅速かつ簡単に読み取り、解釈できるようにしました (図 3、ルート 2b)。

動作検証チェックリストの精査

新しいワークフローの中心的な側面は、エンジニアがタイミング図を読んだりシミュレーションを実行したりするのではなく、チェックリストを使用して Function ブロックの動作の正確性を確認できることです。これらの方法は、特に I/O の数が多い場合には、時間がかかり、エラーが発生しやすくなります。この問題に対処するために、レビュー担当者が最も関心のある情報に重点を置き、簡潔で読みやすい行動検証チェックリストが開発されました。エンジニアは、Simulink を定期的に使用していない、またはインストールしていない場合でも、これらのチェックリストを個別に、またはグループで使用して、各機能ブロックと、入力刺激の変化に対するその Function ブロックの応答を評価できます (表 1)。これにより、設計レビュー プロセスにより多くの専門家が関与できるようになり、テスト エンジニアの負担が軽減されます。結果は複数の人によってオフラインでレビューされるため、論理エラーが検出される可能性が高まります。チェックリストは、Simulink テスト ケースから MATLAB スクリプトを使用して自動生成されます。これは次に Simulink Design Verifier で自動生成されます。

TIA Portal への Simulink テストケースのインポート

ワークフローの最後のセクションでは、ターゲット PLC 環境で Function ブロックを再実装してテストします。まず、2 番目の MATLAB スクリプトを使用して、Simulink テスト ケースを Siemens テスト ケース ファイル (拡張子が .TAT のテキスト ファイル) に変換します (図 4)。また、Simulink の Function ブロック設計を TIA Portal に変換します。最後に、Siemens PLCSIM と Test Suite Advanced を使用して PLC コード上で変換されたテスト ケースを実行し、ターゲット上での同等性を確認します。

TEST_CASE “TEST_OUTPUT_TEST_CASE_1”
 
PROPERTY
AUTHOR : “METCALF”
VERSION : “1.0”
COMMENT : “Test Case 1 for TEST_OUTPUT function block.”
SCOPE : “PSS_PLC”
END_PROPERTY
 
VAR
TEST_INITIAL_CONDITIONS : TEST_OUTPUT_IDB.TEST_INITIAL_CONDITIONS := FALSE;
TEST_CONFIGURED : TEST_OUTPUT_IDB.TEST_CONFIGURED := TRUE;
TEST_REQUESTED : TEST_OUTPUT_IDB.TEST_REQUESTED := FALSE;
TEST_CONTINUOUS_CONDITIONS : TEST_OUTPUT_IDB.TEST_CONTINUOUS_CONDITIONS := TRUE;
MINIMUM_TEST_DURATION : TEST_OUTPUT_IDB.MINIMUM_TEST_DURATION := T#74ms;
TEST_OUTPUT : TEST_OUTPUT_IDB.TEST_OUTPUT;
END_VAR
 
STEP : “STEP_1”
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 399);
END_STEP
 
STEP : “STEP_2”
TEST_CONFIGURED := FALSE;
TEST_CONTINUOUS_CONDITIONS := FALSE;
MINIMUM_TEST_DURATION := T#0ms;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
 
STEP : “STEP_3”
TEST_REQUESTED := TRUE;
RUN(CYCLES := 1);
ASSERT.Equal(TEST_OUTPUT,FALSE);
RUN(CYCLES := 199);
END_STEP
. . . 
. . . 
. . . 
END_TEST_CASE

図 4. Simulink テスト ケースから MATLAB スクリプトによって生成された Siemens テスト ケースの一部。

ワークフローの展開と他のプロジェクトへの適用

PSS のような高信頼性安全システムでは、ソフトウェア エラーが安全でない、さらには壊滅的な結果につながるリスクを最小限に抑えるために、厳格な開発ワークフローが必要です。冗長処理ユニット間でソフトウェア コンポーネントを複製すると、エラーはすべて共通原因 (CC) になるため、リスクはさらに増大します。これらの理由から、IEC 61508 では、ソフトウェアを通じて安全システムに体系的な障害が導入されるのを回避することに重点を置いています。モデルベースデザインと新しいワークフローにより、IEC 61608 で定義されているとおり、体系的能力が向上し、安全でエラーのないシステムを実装していることを非常に高いレベルで保証できるレベルに達しています。

現在、アップグレードされた PSS を残りの加速器セグメントに展開する最終段階にあり (図 5)、完了予定日は 2024 年秋です。PSS の完了後、当社の次の開発優先事項の 1 つは、マシン保護システムの一部であるビーム損失監視 (BLM) システムのアップグレードです。このプロジェクトでは、PSS で使用されるワークフローと非常によく似たワークフローを使用する予定です。ただし、BLM システムのターゲットは FPGA となるため、 HDL Coder™ を使用してSimulinkモデルから直接合成可能な HDL コードを生成し、ターゲット上での手動コーディングをほぼ完全に回避する予定です。また、 HDL Verifier™のハードウェアインザループ機能を使用して、デバイス上の検証および妥当性確認ワークフローを簡素化および高速化したいと考えています。