アラームが鳴り続ける｜しきい値を広げる前に見るヒステリシスと遅延

温度がしきい値の近くで上下し、そのたびに通知が届く。担当者が確認しても、すでに正常へ戻っている。こうした頻発に対して、しきい値を高くするだけでは、本当に知らせたい変化まで遠ざける可能性がある。

先に分けたいのは、発生と復帰を行き来しているのか、短時間の変動を拾っているのか、それとも同じ異常を繰り返し配送しているのかである。本稿は監視通知の見直しを考える記事であり、保護装置やインターロックの設定変更を指示するものではない。

まず「何件届いたか」と「何回発生したか」を分ける

メールが多数届いても、異常の発生回数が同じとは限らない。発生のたびに通知したのか、未確認の状態を定期的に再通知したのか、通信復旧後にまとめて届いたのかで、見る場所が変わる。

最初に、測定値、判定状態、発生時刻、復帰時刻、通知時刻、確認・対応時刻を同じ時間軸へ並べる。通知一覧の受信時刻だけでは、現場でいつ異常だったかを読み違える。収集周期が違う情報を比べる場合は、その違いも残す。

この表は調査の入口である。原因を決めるものではなく、実際に設備が不安定になっている場合は、その現象自体への対応が先になる。

ヒステリシスは、発生と復帰の境界を分ける

上限の警報を例にすると、発生する温度と正常へ戻す温度を別にする考え方がヒステリシスである。デッドバンドとも呼ばれ、境界付近の小さな揺れで発生・復帰が繰り返されるのを抑えるために使われる。OPC Foundationの公式仕様の説明例でも、上限から所定の幅だけ下がるまで正常へ戻さない考え方が示されている。[1]

例えば、説明用の架空条件として「80℃以上で発生、78℃未満で復帰」と決めた場合を考える。79℃台へ戻っても、警報状態は続く。これは80℃の発生境界を高くしたのではなく、復帰の境界を分けたものである。80℃と78℃は原理説明の数値であり、軸受や設備の推奨設定値ではない。

表示画面では「幅」を入力する方式も、復帰値を直接入力する方式も考えられる。等号の扱いを含めて実機仕様で確認し、担当者の理解と設定画面の意味を合わせる。幅を大きくし過ぎて正常復帰しにくくなれば、常時警報に慣れる別の問題を招くため、復帰の状態も評価する。

オン遅延とオフ遅延は、待つ位置が違う

オン遅延は、発生条件が成立してから警報を出すまでの待ち時間に関わる。オフ遅延は、正常へ戻る条件を満たしてから警報状態を解除するまでの待ち時間に関わる。ヒステリシスが値の差を使うのに対し、こちらは時間を使う。Emersonの技術資料は、この三つを別の属性として整理している。[2]

短い変動を除きたい場合でも、発生を遅らせてよいかは別の判断である。対応が必要な異常まで待たせる可能性がある。一方、復帰を遅らせると再発生の繰り返しを抑える方向に働くが、通知を見た人には復旧が遅れて見える。通知の減少だけを成功条件にしないことが要点だ。

前述の架空例へ時間条件を加えるなら、まず「どの状態が、どれだけ続いたら成立するのか」を文章にする。途中で境界を戻った場合に時間をリセットするのか、欠測時はどうなるのかも、製品ごとの仕様を確認する。単に「遅延あり」と記録しても、別の担当者は動作を再現できない。

設定を触る前に、通知後の行動を確かめる

その通知を受けた人は何を確認し、どのくらいの時間内に誰へ連絡するのか。この答えが曖昧なら、頻度だけ整えても対応は定着しにくい。点検依頼でよい情報と、運転員が速やかに対応すべき警報は、役割を分けて設計する必要がある。

Emersonの資料は、プロセス産業のアラーム管理を対象に、原因、放置した場合の結果、対応時間、運転員の行動を整理することを説明している。[2] ここでのアラームの定義を、保全担当への全ての通知にそのまま当てはめるわけではない。ただ、通知を減らす検討で「必要な行動が残るか」を確認する視点は使える。

たとえば、説明用の検討場面として、起動時だけ同じ温度通知が続くなら、起動という状態と実際の温度推移を確認する。通常の現象と確認できていない段階で、起動中の通知を一律に消さない。センサ不良や測定位置の問題なら、判定設定を調整する前に計測系の補修が必要な場合もある。

保存データで、残したい警報を先に決める

見直し案を比較するときは、実際に対応が必要だった期間を先に選び、どの時点までに知らせる必要があったかを確認する。その上で、同じ保存データに変更前後の判定条件を当て、必要な警報が残るかを見る。通知の少ない案を選んでから、都合のよい事例だけを探す進め方を避けたい。

再評価に使える記録の細かさも確認する。たとえば、短時間の変動を検討したいのに、履歴が長い間隔の平均値しか残していなければ、元の発生・復帰を再現できない。保存データで分からない部分は不明とし、承認された範囲で追加の収録や試験を計画する。欠けた波形を推定で埋めて、遅延設定の安全性を確認したことにしない。

再評価で分かるのは、残された条件下での挙動である。今後の負荷や故障を全て含むわけではないため、導入後に何を監視し、どの状態になったら再見直しするかまで決めておく。確認できなかった運転状態も記録に残す。

変更は、一つの設定と一つの履歴を対にする

見直す場合は、変更前後の条件、理由、影響する通知、承認者、適用時刻、復旧方法を残す。運転・保全・計装の担当者で、必要な対応時間を損なわないか確認する。Emersonの資料でも、設定の実装は変更管理と関係者への周知に結び付けている。[2]

変更後は、通知件数のほか、発生から通知までの時間、復帰の遅れ、見逃しが疑われる期間、担当者が実行した行動を見る。運転時間や負荷条件が違う週同士を比べ、件数だけで改善したと判断しない。平常値だけを眺めるのでなく、承認された試験や保存データの再評価で、発生・復帰・欠測の動作を確認する。

設備台帳や点検履歴には、単に「しきい値を変更」と書かず、どの通知にどの条件を適用したかを結び付ける。次に同じ通知が増えたとき、設備の変化なのか、設定や収集方法の変化なのかを追えるからである。

必要な変化を適切な相手へ届け、対応した結果を残す。そのために、発生値・復帰値・時間条件・再通知を分けて確認することが、最初の一歩になる。

参考文献

[1] OPC Foundation『OPC UA Part 9: Alarms & Conditions』v1.05.06、B.1.5 Example for On-Delay, Off Delay and ReAlarmTime。公式の動作説明例を参照。公式仕様

[2] Emerson（2019年10月）『Alarm Rationalization』。4～5ページの定義・属性、11ページの変更管理を参照。本文で紹介するのはメーカー解説であり、ISA・IEC規格全文を確認したという意味ではない。メーカー技術資料