従来、基板検査システムのシステム設計ではアクティビティ図やシーケンス図を作成してシステムの振る舞いを表現してきた。しかしながら、これらで表現できるのは一般的な振る舞いに留まっているのが現状であり、システムが高機能化・複雑化する中で設計段階において異常系の振る舞いを精緻に特定して不具合の混入を防ぐことは難しい。

筆者らは基板検査システムの開発においてシステム安全性解析手法の1つであるSTAMP/STPAの適用を試みた。その結果、従来からあるシステム設計手法では抽出しづらかったであろう不具合発生要因を設計初期段階にて導出することができ、今後、更にシステムが高機能化・複雑化したとしても、信頼性を保ち続けることができる手応えを得た。

本稿では、基板検査システムの開発にSTAMP/STPAに適用した分析事例を述べると共に、本取り組みを通じて得られた分析作業の効率化手段を提案する。

1．まえがき

近年、自動運転技術の発展を支えるADAS（Advanced Driver-Assistance Systems、先進運転支援システム）や、5Gを代表とする通信技術の発展に伴い、SMT（Surface mount technology、基板実装技術）は高密度化、微細部品化が進んでいる。また、社会インフラを支える電子機器の製品安全を実現するためにSMTには高い信頼性と安定性が求められている。SMTの最終工程において、部品が正しく実装されているか、基板と部品が正しくハンダ付けされているか検査を行う基板検査システムは重要な役目を担っている。

基板検査システムに求められる機能も近年、多機能化かつ高機能化している。多様な機能を実現するために、多くのシステムホスト間、アプリケーション間のコミュニケーションが発生することで、システム構成は複雑化の一途を辿っている。加えて、ビックデータやAI向けに画像データの重要性は高まっており、工場内ネットワークにおいて大量・大容量の画像データが高頻度で送受信や読み書きが行われる環境下でも、安定動作し続ける高い信頼性が求められる。

従来、システム設計ではアクティビティ図やシーケンス図を作成してシステムの振る舞いを表現してきた。しかしながら、これらで表現するのは一般的な正常系と、代表的な異常系の振る舞いに留まっているのが現状であり、設計段階で異常系の振る舞いを精緻に特定して不具合の混入を防ぐことは難しく、社内のテスト環境では再現できない問題が、特定の顧客環境で発覚するような不具合が発生していた。

「ZERO DEFECT ～不良を作らない～」生産ラインの構築を目指すオムロンの基板検査システムに求められる高機能性と高信頼性の両方を両立するための設計分析手法として、システム思考に基づく新しい安全性解析手法STAMP/STPAの適用を試みた。STAMP/STPAは複雑なシステムにおいても以前は運用でしか発見できなかった「想定外の想定外（Unknown unknowns）」が、開発プロセスの初期に識別され、除去または低減することができるとされている^1）。

本稿では基板検査システムの開発にSTAMP/STPAに適用した分析事例を述べると共に、本取り組みを通じて得られた分析作業の効率化手段を提案する。

2．STAMP/STPA

2.1 STAMP/STPAとは

STAMP/STPA（Systems-Theoretic Accident Mode and Processes/Systems-Theoretic Process Analysis）はマサチューセッツ工科大学のNancy G Leveson教授が提唱している、システムの構成要素間の相互作用によって発生する問題を分析する手法である^1,2）。航空宇宙分野での適用^3）のみならず、社会インフラ領域への適用が広まっている^4）。

従来から存在する分析手法FTA（Fault Tree Analysis）やFMEA（Failure Mode and Effect Analysis）は機器や組織の単一故障を分析する手法として1960年代から存在している。これらの分析手法は現代において進化し続ける複雑なシステムにおいては限界がある。なぜならば、複雑なシステムにおいては単一コンポーネントの故障のみならず、コンポーネント間のコミュニケーション・ミスマッチが事故を引き起こすと考えられるためである。Nancy G Leveson教授が提唱しているSTAMP/STPAはトップダウンプロセスをとり、システム内の各コンポーネントが直接的、間接的に発生する相互作用を俯瞰的に捉えて偶発的に発生する創発特性を制御して事故を防止する考え方に基づく。

2.2 STAMP/STPA分析手順

STAMP/STPA分析の手順を以下に示す。

Step0：（準備1）アクシデント、ハザード、安全制約の識別
対象システムにおいて分析対象となるアクシデント、ハザードを定義する。アクシデントは利害関係者にとって受け入れられない何らかの価値が喪失するという広い意味で定義される。ハザードとはアクシデント一歩手前の、放置してはいけない状態である。最後にハザードを制御するためのシステム上の安全制約を識別する。

Step0：（準備2）コントロールストラクチャの構築
システムにおいて、安全制約の実現に関係するコンポーネント（サブシステム、機器、組織等）、及び、コンポーネント間の相互作用を分析し、コントロールストラクチャを構築する。図1に一般的なコントールストラクチャを示す。

Step1：非安全なコントロールアクション（UCA）の抽出
安全制約の実行に必要なコントローラによるコンポ―ネント間の指示（Control Action）を識別して、識別された指示の中からUCA（Unsafe Control Action、非安全制御動作）を抽出する。UCAを抽出する際のヒントとして4つのガイドワードがある。

• Not Providing：与えられないとハザード
  安全のために必要とされるコントロールアクションが与えられないことがハザードにつながる。
• Providing causes hazard：与えられるとハザード
  ハザードにつながる非安全なコントロールアクションが与えられる。
• Too early/too late, wrong order causes hazard：早過ぎ、遅すぎ、誤順序でハザード
  安全のためのものであり得るコントロールアクションが、早すぎて、遅すぎて、または順序通りに与えられないことでハザードにつながる。
• Stopping too soon/applying too long causes hazard：早過ぎる停止、長過ぎる適用でハザード
  安全のためのコントロールアクションの停止が早過ぎる、もしくは適用が長過ぎることがハザードにつながる。

Step2：ハザード要因（HCF）の特定
Step1で抽出したUCA毎に、関係するコントローラと制御対象プロセスを識別してコントロールループ図を作成し、因果関係シナリオ生成の抽象モデルを参照しながらHCF（Hazard Causal Factor、ハザード誘発要因）を特定する。

コントロールループ図とは、着目したUCAに関係するコンポーネントのみを抜き出した図であり、複数のコンポーネント間の相互作用を同時に考えるではなく、二つのコンポーネントに絞って考えるためのものである。

因果関係シナリオ生成の抽象モデルとは、HCFの特定を支援するモデルであり、HCFの一般的発生理由が記載されている。

3．基板検査システム開発への導入

3.1 事前準備

本取り組みは図2に示す検査システム事業部の開発プロセスのうち、赤い囲み線で示した概念設計からシステム設計フェーズの間にかけて実施した。

分析に際し、事前準備として図3に示すシステム全体の概略図を作成し、システムに対する理解を分析者の間で共有できるようにした。システム構成要素の役割について説明する。

• ティーチング端末：基板検査に必要な検査プログラムの作成、編集を行う。
• プログラムサーバ：検査プログラムを保存する。
• ラインサーバ：いくつかの生産ライン毎に設置し、検査プログラムのレプリカサーバとしての役割と、検査結果および検査結果画像の一次保存場所となる。
• Q-upサーバ^5）：Database Systemを搭載して検査結果の分析を実施する。
• 検査装置：基板の良否判定を実施する。
• 目視端末：検査装置が不良品判定した基板に対し、目視検査作業者の目視検査によって良否の最終判定を実施する。

3.2 Step0（準備1）：アクシデント、ハザード、安全制約の識別

システムのアクシデント、ハザード、安全制約は以下のように定義した。

アクシデント：

• オムロンが提供する検査システムアプリケーションが原因で生産ラインが停止する

ハザード：

• 検査装置の起動に時間がかかり検査を開始できない状態
• 検査機で検査プログラムの読込みができず、検査機種切り替えができない状態
• 目視端末で、目視検査対象の基板が端末内に到着しているのにも関わらず目視検査が実施できない状態
• 検査プログラムの内容に不整合が生じ、検査機が異常を検知して停止する状態
• 基板が装置手前に到着して装置内に基板が無いのにも関わらず、基板を搬入しない状態
• 検査が完了して下流装置が搬入可能状態にも関わらず、基板を搬出しない状態

安全制約（ハザードの裏返し）：

• 生産開始のタイミングまでに検査が実施できる状態でなければならない
• 検査機で検査プログラムが正常に読み込めて、段取りが実施できなければならない
• 目視端末に基板が到着した時点で目視検査を開始できなければならない
• 検査プログラムの不整合によって検査機が異常停止してはならない
• 基板が到着し、装置内に基板が無いのであれば基板を搬入して検査を開始しなければならない
• 検査を完了して下流装置が搬入可能状態ならば速やかに基板を搬出しなければならない

3.3 Step0（準備2）：コントロールストラクチャの構築

本ステップで構築したコントロールストラクチャを図4に示す。この図が示すように、システムの大まかな構成要素が決まる概念設計の段階から適用できるのが、STAMP/STPA の特徴でもある。

図3に示した概略図とはシステム構成要素に変化がある。これは、設計の過程において変更が発生したことを表している。

3.4 Step1：非安全なコントロールアクション（UCA）の抽出

総計51個のUCAを抽出した。抽出したUCAの例を示す（表1）。

UCAの抽出においては、文脈にコンテキスト（状況）を含めることが重要である。コンテキストを含んだUCAの表現がしにくい場面に遭遇した際には「～にも関わらず、～だ」という表現を用いるよう心掛けた。例えば「検査結果の出力が遅れる」というUCAがあった場合に、「次の検査対象基板到着するまでに検査結果の出力が完了しなければならないのにも関わらず、検査結果の出力が完了しない」という表現にする。

3.5 Step2：ハザード要因（HCF）の特定

本取り組みでは総計85個のHCFを抽出した。抽出したHCFの例を示す（表2）。

問題を単純に扱えるようにHCFの抽出において、以下の点に留意した。

風が吹けば桶屋が儲かるということわざがある。一見すると全く関係がないと思われる場所・物事に影響が及ぶことの喩えであり、因果関係を深く追っていくと、何もかもが問題の要因となり得る事を示唆している。本取り組みでは問題をシンプルに取り扱うために、因果関係は1次までにとどめるようにした。風が吹くと桶屋が儲かるの例で例えると、突風で砂ぼこりが立つ、その結果、砂ぼこりが目に入り視力を失う人が増える、までに留める。HCFの表現にならうと「突風により砂ぼこりが立つ」とし、その対策として「風が強い日は水を撒いて砂ぼこりが舞わないようにする」といった具合である。

図4で示したように、基板検査システムは複数のコンポーネントがネットワークで接続された構成をしている。STAMP/STPAの手順ではコンポーネント間の指示に着目し、コンポーネント間の相互作用によって発生する問題を抽出するため、同じようなHCFが複数のホスト間で重複して抽出された。対策を検討するにあたりHCF個々に対策を立てるのではなく、HCFを集約し、集約されたHCFごとに対策を検討するようにした。結果としてHCFのばらつきや抽出の漏れを炙り出すとともに、対策検討をしやすくする効果があった。集約したHCFとHCF抽出シナリオの例を示す（表3）。

3.6 HCF 対策の立案

STAMP/STPAで定義された手順はHCFの特定までであるが、基板検査システム開発プロセスの中で抽出された各HCFを排除するための方策を検討し、システム仕様あるいは、各アプリケーションの機能仕様にフィードバックする。

4. 考察

STAMP/STPAのプロセスを実施することで新たに抽出できたUCAとしては以下のような内容があった（表4）。

コントロールストラクチャをベースに検討することで、システム全体を俯瞰でき、本来の目的を意識したうえで、構造上不足している点を見つけることができた。

一見するとよくある不具合のように見受けられるが、これらアクティビティ図やシーケンス図では振る舞いを表現しづらく、処理タイミングによっては問題が発生する場合があるようなリスクを抽出できている。これらのリスクに対し、開発終盤のテスト段階もしくは顧客環境にて実際に問題が発覚してから個別に対処するのではなく、開発プロセスの初期から問題を把握し、分析を通して得られた図表を介して開発メンバー間で共有した上で本質的な対応を取れることは、開発プロジェクトにQCDの観点で貢献するものと考える。

STAMP/STPAの導入における分析作業は、Step1：UCAの抽出件数ごとに、Step2：HCF特定を繰り返すため、分析作業量が多くなる。本手法の活用を広めるためにはSTAMP/STPAが持つ創発特性の制御能力を維持しつつ、分析作業の効率化が必要であると考える。本取り組みでは、HCF対策検討時に個別に抽出したHCFの集約を行い検討立案の効率化を図った。更なる効率化の手段として、Step1：UCAの抽出までを実施した後で、同じようなコンテキストで発生するUCAの集約を行い、集約されたUCAに対してHCFを検討する方法が考えられる。特に、基板検査システムのような分散システムにおいては、ホスト間のネットワーク接続に起因するHCFは集約して検討できるため有効である。

5. むすび

今後、求められる要求の多機能化・高機能化が予測される中でも高品質なシステム開発の実現に向けて、基板検査システムの設計にSTAMP/STPAを適用し、オムロンが提供する検査システムアプリケーションが原因で生産ラインが停止することをアクシデントと定義してSTAMP/STPAによる安全性解析を試みた。

システム全体をコントロールストラクチャで表現して俯瞰しながら、ガイドワードを照らし合わせてコンポーネント間の指示によって発生し得る問題を抽出することで、アクティビティ図やシーケンス図の作成だけでは抽出できないような異常系の振る舞いに対するリスク項目を導き出すことができた。

STAMP/STPA分析の過程でシステム全体を可視化して問題とその問題に至るまでのコンテキストおよび、対策のトレーサビリティを残せることでドメイン知識の形式化に寄与すると共に、今後、更にシステムが高機能化・複雑化したとしても信頼性を保ち続けることができる手応えを得た。

一方で、分析作業には根気と労力を要する。開発プロジェクトにおけるSTAMP/STPAの適用障壁を下げて、活用機会を増やすためには、分析作業の効率化が不可欠だと考える。本取り組みでは、個別に抽出したHCFを集約し、対策検討の効率化を図った。また、同じようなコンテキストを有するUCAの集約による、HCF抽出の効率化を提案した。

今後もこのSTAMP/STPAを活用し、システム製品の信頼性向上に貢献していくと共に、分析時に工夫した点や基板検査システムならではの肝所を蓄積し、より設計に適用しやすくなるよう努めていく所存である。

参考文献

1）

Leveson, Nancy G.; Thomas, John P. “STPA Handbook”. http://psas.scripts.mit.edu/home/get_file2.php?name=STPA_handbook_japanese.pdf,（参照 2020-8-4）．

2）

情報処理推進機構．“はじめてのSTAMP/STPA ～システム思考に基づく新しい安全性解析手法～”．情報処理推進機構．https://www.ipa.go.jp/files/000051829.pdf，（参照2020-8-4）

3）

氏家 亮．JAXA コウノトリプロジェクトへのSTAMP/STPA適用例．計測と制御．2016, Vol. 55, No. 5, p. 405-409.

4）

北村 知．JR 東日本におけるSTAMP活用の取り組み．SEC journal. 2018, Vol. 13, No. 4, p. 30-37.

5）

オムロン株式会社．“「品質起点」の生産性向上支援ソフトウェア Q-up System”．https://www.fa.omron.co.jp/data_pdf/cat/q-upnavi_scwb-046a-1.pdf?id=1463,
（参照2020-10-20）．