綺麗なコードを書くより、「意地悪な検証」ができる人が現場では生き残ります。
設備のためではありません。
「未来の自分」がフォローに回ることを防ぐ為です。
私が試運転で必ず実行する、 自分を守るための
【トラブル確認リスト】を置いておきます。
これをサボると、数億円の損害か、あなたの睡眠時間が消えます。
現場に入る全エンジニアに共有してみてください。
① 物理的な嫌がらせ（安全確認）
・センサ位置を限界までズラして誤検知させる
・ドリルで穴を開けた「確定不良品」を実際に流す
・重量搬送中にドアロックをガチャガチャ弄る
・画面、ブザー、タワーが仕様通りか目視
「たぶん止まる」はバグです。
物理的に止まるか確認してください。
② 論理の整合性（定義確認）
・即停止と定常停止（サイクル停止）の挙動確認
・画面上の異常名と内部アドレス/復帰手順の一致
特に「名称不一致」は、トラブル時に保全担当を混乱させ、解決を遅らせる元凶です。
③ データの嘘を見抜く ※最重要
一番怖いのは停止そのものではなく
「再開後のデータ矛盾」です。
・シフト情報（トラッキング）と実ワークの一致
・不良判定が復帰後に「良品」に化けていないか
・MES通知やカウンタの数値ズレ
機械は止まっても、データが生きていればセーフ。
データが死ねば（市場流出）、致命傷です。
④ 現状復帰の徹底実機アラームが出せず「信号強制」で試した場合の落とし穴。
・強制ONや変更したタイマー値の戻し忘れ
・機器側アラームのリセット連動確認
「テスト設定のまま出荷」はエンジニアの恥。
可能な限り実機で出しますが、無理なら回路図と取説を突き合わせて確認してください。
【結論】
確認の目的は「異常発報」だけではありません。
「正しく止まり、安全に復帰し、再運転できること」
までがセットです。
優しさより、サディスティックな検証があなたを救います！
