試運転には匂いがある。熱を持った電気盤、段ボールの粉、午前2時に冷めきったコーヒー。そして私が恐れる音もある。本来動いているはずのコンベヤラインの沈黙だ。
先週、Inland Empire の立ち上げ現場にいた。アパレル返品を扱う 8 万平方フィートの 3PL で、既存のコンベヤ制御に新しい WCS を入れるところだった。パレットが分岐部で止まって動かなくなった。WCS のモニタには明るい緑の文字で「RELEASED」と出ていた。PLC 盤の前の制御エンジニアは I/O ランプを見つめて言った。「リリースは受け取っていません」。
そのパレットのために 2 日を失った。原因はほぼ恥ずかしいものだった。WCS のプログラマは信号テーブルのリビジョン 7 を見て作業していた。現場の PLC が動いていたのはリビジョン 9 だった。その間に現場の作業員が配線を 2 度引き直し、光電センサを 2 つ追加し、誰もテーブルを更新しなかった。リリース要求は、PLC プログラムにとって何の意味もない予備アドレスに届いた。そのチャネルを聞いている者はいなかった。
二十年でこの映画を何十回も見てきた。ハードは問題ない。両方のソフトウェアも問題ない。統合を殺すのは、その間にある文書、つまり I/O 信号テーブルだ。後で祟られないテーブルの作り方を紹介する。
Excel を開く前に、すべての信号を 3 つの箱に仕分ける
新人の失敗は、スプレッドシートを開いて延々と行を打ち込み、信号が 100 行になった頃には半分が何をするのか分からなくなることだ。私は先に仕分けしてからリスト化する。
箱その1：指令、WCS→PLC。 開始、停止、リリース、リセット、モード切替。応答を必要としない指令は削除する。PLC が応答しなくてよいなら、真夜中に故障したときにトラブルシューティングの手がかりが何もないからだ。
箱その2：状態、PLC→WCS。 定位置、運転中、故障、非常停止、手動/自動モード。状態は読み取り専用。WCS は見るだけで、決して書かない。多くのプロジェクトがまさにここで死ぬ。WCS のプログラマが近道をして、PLC が所有するステータスビットに直接書き込むのだ。書き手が 2 人、ビットが 1 つ、試運転で信号がちらつき、バグの正体は「味方の誤射」だったりする。
箱その3：ハートビート。 WCS が 1〜2 秒ごとにビットを反転させ、PLC がそれに応えてビットを反転させる。互いに相手の脈を監視し、止まったらアラームを上げる。テーブル全体で最も安い保険であり、コスト削減の名の下に最もよく削られるものだ。言い分はいつも同じ。「リンクが落ちたらネットワークスイッチがアラームを上げる」。スイッチのアラームはケーブルが切れたことを教えてくれる。ハートビートは、向こう側の機械が生きているのか、死んでいるのか、それともプログラムがハングして脳死状態なのかを教えてくれる。別の事実であり、午前2時にはその違いが重要になる。
「パレットを1つリリースする」を例に取ろう。必要な信号はちょうど4つ。リリース要求（WCS→PLC）、要求受領（PLC→WCS）、リリース完了（PLC→WCS）、そしてハートビートだ。信号4つ、仕事は1つ、所有関係は明確。「これは何のためで、誰が書き、誰が読むのか」に答えられない行は削除する。信号テーブルは長いほど優れているわけではない。保守されていない信号は、試運転が横道にそれたときの容疑者が1人増えることと同じだ。
3ステップ・ハンドシェイクと、2ステップが火傷のもとである理由
私のタイミングチャートは3ステップで、ここは譲らない。WCS が「リリース要求」を立てる。PLC がそれを見て「要求受領」を立てる。PLC がリリースを実行し、パレットが到着したら、PLC が「リリース完了」を立てる。WCS が「完了」を見て「要求」を落とす。PLC が「要求」が消えたのを見て「完了」を落とす。きれいなアイドル状態に戻って一周完了だ。
なぜ3ステップか。両方の近道の代償を私は自ら払ってきたからだ。近道その1：WCS が撃ちっぱなしにする。要求が出て、信号のバウンスで PLC が取りこぼし、パレットはリリースされない。でも WCS はリリースしたと思い込んで次のタスクを出す。ライン全体が詰まる。近道その2：PLC は動くが報告しない。リリースは起きたが WCS は知らず、タイムアウトして要求を再送し、同じパレットが2度リリースされる。下流の分岐部はデモリション・ダービーと化す。
3ステップ・ハンドシェイクの要点はクローズドループだ。前のステップが確認されるまで何も進まず、リセットが確認されるまで何も戻らない。誰も語らないおまけもある。どちらかの側がネットワークを失ったりハングしたりすると、ハンドシェイクはステップの途中で凍結する。目に見えて、うるさく、アラーム付きで。凍結は問題ない。殺しに来るのはサイレント障害だ。3つ先のパレットで気づいたときには、もう手遅れになっている。
どの現場でも回す試運転前チェックリスト
テーブル完成、コード完成——まだ全ライン統合には行かない。先にこの単体テストを回す。試運転の夜の涙のおよそ半分を救ってくれる。
まずデバウンス。 光電センサや近接スイッチは機械的エッジでバウンスする。PLC プログラムでの数十ミリ秒の入力デバウンスは最低条件だ。WCS 側も1回のスキャンを信用してはいけない。状態変化を受け入れる前に2回連続のスキャンを要求する。バウンスはテストでは見えず、物量がピークのときにちょうど顔を出す。
アドレスを監査する。 テーブルを持って、すべての信号を PLC プログラム内の実際のアドレスと1つずつ突き合わせる。現場での配線変更や土壇場の追加はどのプロジェクトでも起きる。テーブルのリビジョンとプログラムのリビジョンは一致しなければならない。私の今のルール：テーブルはリビジョン番号を持ち、その番号は PLC プログラムのコメントと WCS の設定の両方に現れる。冒頭の話のリビジョン7対9の惨事は、まさにこれで防げる。
ケーブルを抜く。 ネットワークケーブルを抜いて、WCS が PLC の喪失に気づくまでの時間を測る。それがハートビートテストだ。非常停止を押して、WCS が見る「非常停止」状態が機械の実際の動作と一致するか確認する。ここでの原則：非常停止回路そのものはハードワイヤードの安全リレーで動く。WCS に送られる「非常停止状態」は単なるミラーだ。安全機能をソフトウェア信号にぶら下げてはいけない。
モード信号をテストする。 PLC が手動になったら、WCS は知らなければならない。そしてタスクの投入を止めなければならない。かつて、技術者がコンベヤを手でジョグしているのに WCS がリリースを送り続けるのを見たことがある。誰も予期しないリリース指令でパレットが押し出された。誰も怪我はしなかったが、運が良かっただけで、設計ではない。モードは安全項目であり、オプションではない。
そしてソークテスト。 ランダムな非常停止、ランダムなネットワーク切断、ランダムな手動介入を混ぜながら、2時間の連続運転。試運転の時間はプロジェクトで最も高くつく時間だ。故障は顧客の前で演じるより、リハーサルで済ませる方がいい。
明日試運転の現場に入るなら、1つ持っていくものがある。印刷した信号テーブル。両者が署名し、リビジョン番号がコードと一致しているもの。それだけで故障モードの半分を塞げる。残りは上のチェックリストが1項目ずつ片づけてくれる。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
