半導体設備保全のアラーム初動対応・インターロック確認手順

工場で機械を使っていると、突然止まることがあります。

半導体を作る装置でも同じです。

ある日、装置が突然止まりました。

画面を見ると、こんな表示が並んでいます。

• 冷却水の圧力が低い
• 温度が高い
• 処理用の電力が止まった
• 処理が中断された

4つも異常が出ています。

では、4か所が同時に壊れたのでしょうか。

実は、そうとは限りません。

ここが、設備保全の仕事を理解するうえでとても大切なポイントです。

---

アラームに書いてある場所が、壊れた場所とは限らない

まず知ってほしいのは、

アラームは「原因を教えてくれる表示」ではない

ということです。

アラームが教えてくれるのは、

「ここでおかしな状態を見つけました」

ということです。

たとえば車で考えてみましょう。

車を運転していて、エンジンの温度が高くなったとします。

だからといって、

「温度計が壊れた！」

とは限りません。

冷却水が減っているのかもしれません。

冷却用のファンが動いていないのかもしれません。

温度を測るセンサーがおかしい可能性もあります。

つまり、

画面に出た症状と、本当の原因は別かもしれない

ということです。

半導体装置でも同じです。

---

まず見るのは「何が最初に起きたのか」

先ほどの4つの表示を、起きた順番に並べてみます。

1. 冷却水の圧力が下がった
2. 装置の温度が上がった
3. 処理用の電力が止まった
4. 処理が中断された

こうして見ると、少し景色が変わりませんか。

最初は4つの故障に見えました。

でも、

冷却水の圧力が下がった
↓
十分に冷やせなくなった
↓
温度が上がった
↓
装置が危険を避けるために処理を止めた

という一つの流れだった可能性があります。

もちろん、この時点ではまだ本当の原因だとは断定できません。

ですが、

「最後に出たアラーム」だけを見るより、ずっと原因に近づけます。

一つの異常がきっかけになって、その後に別のアラームが次々と出ることがあります。

これを専門用語では、

Alarm Cascade（アラーム・カスケード）

と呼びます。

名前は難しそうですが、意味は単純です。

一つの異常から、アラームが連鎖して出ること

です。

---

では「最初のアラーム」を探せばいい？

ここでも、もう一段考える必要があります。

たとえば、

「冷却水圧が低い」

というアラームが最初だったとします。

だから、

冷却水圧低下が最初の異常だ

と決めていいでしょうか。

実は、まだ分かりません。

アラームが出る前から、冷却水の圧力が少しずつ下がっていた可能性があるからです。

たとえば、

正常
↓
少し低下
↓
さらに低下
↓
設定された限界を超える
↓
アラーム発生

という流れかもしれません。

つまり設備保全担当者が探したいのは、

最初に鳴ったアラームではありません。

本当に探したいのは、

装置がいつ最初に「いつもと違う状態」になったのか

です。

この最初の変化を、

First Abnormal Event

と呼ぶことがあります。

日本語にすれば、

「最初の異常事象」

くらいの意味です。

専門用語より、

「いつからおかしくなり始めた？」

と覚えた方が分かりやすいでしょう。

---

どうやって「いつから」を調べるの？

そこで使うのが、装置に残っている記録です。

半導体装置では、

• 何時にアラームが出たか
• その前にどんな操作があったか
• 圧力はいくつだったか
• 温度はいくつだったか

などが記録されていることがあります。

設備保全担当者は、その記録を見ながら、

10時02分　冷却水圧が少し低下
10時03分　さらに低下
10時04分　温度上昇
10時05分　処理停止

のように並べていきます。

すると、

「装置が止まった瞬間」ではなく、「異常が始まった瞬間」

が見えてきます。

---

でも画面の数字は、本当に正しい？

ここでもう一つ問題があります。

画面に、

冷却水圧が低い

と表示されていたとします。

では、本当に水の圧力が下がっているのでしょうか。

これも、すぐには分かりません。

なぜなら、装置の画面が配管の中を直接見ているわけではないからです。

流れをものすごく簡単にすると、

水の圧力
↓
測る部品
↓
電気の信号
↓
装置のコンピューター
↓
画面に表示

という順番です。

たとえば家庭用の体温計でも同じです。

本当の体温が39℃なのか。

それとも体温計が壊れて39℃と表示しているのか。

画面だけでは区別できません。

半導体装置でも、

本当に設備側がおかしいのか

それとも

測っている側がおかしいのか

を分けて考えます。

---

ここでSensorやPLCという言葉が出てくる

ここまで理解できれば、専門用語はそれほど難しくありません。

圧力や温度を測る部品を、

Sensor（センサー）

と呼びます。

センサーが測った情報を、

Signal（信号）

として装置へ送ります。

その信号が装置へ入る入口を、

I/O（入出力）

と呼びます。

そして、その情報を見て、

正常なのか
異常なのか
装置を動かすのか
止めるのか

を判断する制御装置の一つが、

PLC

です。

全部を一度に覚える必要はありません。

まずは、

実際の状態
→ 測る
→ 情報を送る
→ 装置が判断する

という流れだけ理解できれば十分です。

---

一瞬の数字ではなく「変化」を見る

設備保全担当者は、装置が止まった瞬間の数字だけを見るわけではありません。

たとえば冷却水圧が、

ずっと5だったのに突然2になったのか。

5
↓
4.8
↓
4.5
↓
4.0
↓
3.0

と少しずつ下がっていたのか。

この違いはかなり重要です。

そこで、

時間とともに数字がどう変わったのか

を見ます。

たとえば横軸が時間、縦軸が水圧のグラフです。

こうした時間変化の記録を、

Trend Data（トレンドデータ）

と呼びます。

つまり難しく考えなくて大丈夫です。

数字の履歴

です。

これを見ると、

「装置が止まる10分前から水圧が下がっている」

といったことが分かる場合があります。

すると、

「突然壊れた」

と思っていた故障が、

実はその前から少しずつ悪くなっていたこともあります。

---

設備保全は「犯人探し」に少し似ている

ここまでの流れを整理してみます。

装置が止まりました。

まず確認できた事実は、

冷却水圧の表示が下がっていた。

これだけです。

まだ、

冷却水設備が壊れた

とは言えません。

そこで、

実際に水圧が下がったのでは？

という原因候補を考えます。

同時に、

圧力を測るセンサーがおかしいのでは？

という別の候補も考えられます。

そして、それぞれを安全な方法で確認します。

この考え方には名前があります。

実際に確認できたものが、

Fact（事実）

です。

まだ確認できていない原因候補が、

Hypothesis（仮説）

です。

その仮説が正しいか確かめることを、

Verification（検証）

と呼びます。

そして最後に、

「今回の停止を起こした本当の原因はこれだった」

と確認できたものが、

Root Cause（根本原因）

です。

でも、この英語を覚えることが重要なのではありません。

大事なのは、

見えた症状だけで決めつけない

考えられる原因を出す

一つずつ確かめる

という考え方です。

---

Resetして動けば修理完了？

もう一つ大事なことがあります。

装置が止まったとき、

Resetを押したら動き始めた。

すると、

「直った！」

と思いたくなります。

でも、本当に直ったのでしょうか。

たとえば家庭のブレーカーが落ちたとします。

ブレーカーを戻したら電気がつきました。

でも、なぜブレーカーが落ちたのか分からないままなら、また落ちるかもしれません。

装置も同じです。

再起動できたことと、

原因がなくなったことは別です。

だから設備保全では、

なぜ止まったのか
同じことがもう一度起きないか

まで確認します。

---

では、装置が止まったら最初に何を見る？

ここまでを、できるだけ簡単にまとめます。

装置が止まったら、

まず安全を確認します。

そのうえで、

① どんなアラームが出たかを見る

でも、それだけで故障箇所を決めません。

次に、

② 何が最初に起きたかを見る

アラームやイベントの時刻を確認します。

そして、

③ その前から数字が変化していなかったかを見る

圧力や温度などの履歴を確認します。

さらに、

④ 本当に設備がおかしいのか、測定側がおかしいのかを分ける

という考え方をします。

最後に、

⑤ 原因候補を一つずつ確かめる

という流れです。

---

設備保全担当者の仕事は「アラームを消すこと」ではない

設備保全の仕事というと、

「壊れた部品を交換する人」

というイメージがあるかもしれません。

でも実際には、その前の仕事がとても重要です。

装置が止まった。

アラームが出た。

数字が変わった。

では、

なぜそうなったのか。

これを、

装置の記録や状態を見ながら一つずつ考えていきます。

つまり設備保全担当者は、

画面に出た症状から、本当の原因を探していく仕事

でもあります。

製造業で、

「機械がおかしいとき、音や温度や動きを見ながら原因を探した」

という経験がある人なら、その考え方は半導体装置でもつながっています。

---

まとめ

この記事で一番覚えてほしいのは、これです。

アラームは答えではありません。

アラームは、

「ここで何かがおかしいよ」

と教えてくれる入口です。

そこから、

いつ最初に変わった？
本当に設備がおかしい？
数字を測る側は正常？
他の数字はどう変わった？

と一つずつ確認します。

そして、

症状 → 原因候補 → 確認 → 本当の原因

と進んでいきます。

これが、半導体製造装置の設備保全で使われる基本的な考え方です。

読み終わった今、

Alarm Cascade、Sensor、Trend Data、Root Cause

という言葉も、最初より少し意味が分かるようになっているはずです。