はじめに：同じアラーム、3つのシフトで3通りの処置
ある金属粉末床溶融結合装置で、夜勤中に「酸素濃度過高」の通知が連続して表示された。Aシフトは経験に基づいて造形を継続し、Bシフトは装置を停止して再パージを行い、Cシフトは単にリセットした。3件の記録はいずれも同じ現象を記しているが、「この通知はどのイベントコードに対応するのか、発報閾値はいくつか、造形継続は許可されるのか、リセット後に再検証が必要か」という問いに答えられるものはない。Blueprint 3Dは、設計図面から実製品の納入までを対象とするライフサイクルプロジェクトを受託する中で、現場にはセンサーも点検表も不足していない一方、装置コントローラが出力する生イベントを判断可能な動作へ変換する統制済みコード表が欠けていることを見出した。本稿で扱うのは「装置をどう修理するか」ではなく、そのさらに上流にある層、すなわちアラームおよびイベントコード自体をどう番号付けし、どう階層化し、どうインターロック動作に結び付け、マスキングとリセットをどう統制し、ファームウェアバージョンに合わせてどう凍結するかである。これにより、同じイベントにはどのシフトでも同じ処置が行われるようにする。
1. まず境界を明確にする：アラームコード、故障現象、品質イベントは同じ表ではない
混同されやすい3種類の対象をまず分離する。アラームコードは、装置制御システムがビットまたはワードで出力する構造化識別子であり、その意味はコード表で定義され、一意性、安定性、機械可読性が求められる。故障現象は、例えば「粉末敷設に筋がある」のように作業者が観察する記述であり、自然言語に属し、複数の現象が同一コードを指してもよい。品質イベントは、「当該 build を隔離して検査待ちとする」のような、部品への影響について事後に下す判定であり、リリース判定の層に属する。すでに論じられている電力品質の3段階測定点と波形記録、予知保全における故障モード・監視指標・閾値のマッピング、設備点検における正常・異常・再確認要の3状態は、いずれもある種のイベントを利用して別の判断を行うものであり、「コードはどこから来るのか、コード領域をどう分けるか、コード変更時に旧記録をどう扱うか」を定義するものではない。この層を見分ける問いは、「この文書は、信号を受け取った後に結論をどう算出するかを扱うのか、それとも、この信号が発生時点で何と呼ばれ、どのレベルに属し、どの動作を発動できるかを扱うのか」である。「1つのコード、1つの階層表、1つのインターロック規則、1件のバージョン凍結記録」に帰着できるものが、コード表エンジニアリングの層である。
2. コード領域の区分：すべてのイベントに再利用されない識別番号を与える
5セグメントの固定長コードを推奨する：E-<装置ファミリー2桁>-<サブシステム2桁>-<連番3桁>-<レベル1桁>。例えば、LP-GS-0217-3 は、粉末敷設／ガス系サブシステムのイベント番号217、重大度レベル3を示す。装置ファミリーはプロセスプラットフォーム別に区分する（LP：レーザー粉末床溶融結合、BJ：バインダージェッティング、PJ：光造形、DE：指向性エネルギー堆積）。サブシステムは機能領域別に区分する（GS：ガス系および酸素濃度、RC：粉末敷設およびリコーター、LS：レーザーおよび光学系、TH：基板予熱、MT：モーションおよびサーボ、PW：電源およびユーティリティ、CT：制御および通信）。コード表では、各コードについて少なくとも8つの項目を固定する。一意コード、中国語および英語の標準記述、発報条件式、デフォルトレベル、デフォルトのインターロック動作、発生が許容される運転状態、初回有効化ファームウェアバージョン、対応責任部署である。連番は一度割り当てたら再利用しない。イベントを廃止する場合は deprecated と表示し、履歴マッピングを保持するだけとする。旧番号を新しい意味に割り当てることは禁止する。さもなければ、3年前の品質記録が追跡時に全く異なるイベントとして解釈される。
3. 階層化とインターロック：「通知」から「安全停止」までの4状態動作マトリクス
4段階の重大度を推奨し、各レベルを一意のデフォルト動作に結び付けることで、現場の裁量を排除する。S1は通知（イベントログへの記録のみで造形は中断しない。例：フィルター差圧が交換推奨値に近づいた場合）、S2は警告（造形を継続するが、減速またはマーキングする。例：チャンバー内酸素濃度が800～1000 ppmの範囲に上昇した場合、層間パージを自動延長し、当該層にマークを付与する）、S3はプロセス保持（粉末敷設を一時停止し、現在の層番号および不活性雰囲気を維持する。例：酸素濃度が1000 ppm超の状態が2秒以上継続、またはレーザー実測出力が設定値から±8%逸脱した状態が3層を超えて継続した場合。造形再開前に、当該層の上下各3層の溶融結合状態を再確認する必要がある）、S4は安全停止（レーザー出力を遮断し、ガス循環を維持し、当該 build を直ちに隔離する。例：保護ガスの供給中断、チャンバードアのインターロック作動、非常停止回路の作動）。S4は自動リセットおよびマスキングを一律に禁止する。動作マトリクスは「レベル → 中断の要否 → 雰囲気維持の要否 → build隔離の要否 → 初品再検証の要否 → 通知先」の6列で記載し、プロセス、設備、品質の3部門が共同承認した後に発行する。
4. デバウンス、発報条件、エビデンススナップショット：イベントを再計算可能にする
発報条件は単に「酸素濃度が高い」と記載してはならず、再計算可能な式として記載する必要がある：比較値 / 比較演算子 / 閾値 / 継続時間 / ヒステリシス帯 / 有効化運転状態。例えば酸素濃度では、閾値を1000 ppm、継続時間を2秒、ヒステリシス帯を5%（950 ppm未満まで低下して初めて解除）、有効化運転状態を造形および予熱時のみとし、待機および保全時には判定しない。レーザー出力偏差では、±8%、連続3層、100 msのサンプリング周期によるデバウンスを採用し、連続3周期で成立した場合に確認する。50 ms未満の瞬間的スパイクは過渡現象として記録し、レベルを引き上げない。確認済みイベントごとにエビデンススナップショットを生成し、以下の10項目を固定することを推奨する：イベントコード、タイムスタンプ（装置クロックと同期し、ドリフトは1秒以下）、当時の層番号、レーザー実測出力、粉末敷設軸位置、酸素濃度および露点、パラメータパッケージハッシュ、コード表バージョン、ファームウェアバージョン、作業者識別子。さらに、イベント発生前200 msおよび発生後1秒の主要変数波形を保持する。このスナップショットがなければ、事後にイベント影響範囲を判定できず、S3/S4のリリース判断にも根拠がなくなる。
5. マスキング、リセット、一時バイパス：例外を承認の枠内に閉じ込める
現場では、例えば酸素分析計の校正期間中など、正当なマスキングが必要になる場合がある。しかし、これには工学的な制約を設けなければならない。マスキングはS1～S3にのみ許可し、S4は恒久的に禁止する。申請書には、コード番号、理由、代替監視手段、有効期間を明記する。有効期間は8時間以下または1 build以下を推奨し、いずれか早い時点で自動的に失効させる。実行には設備部門と品質部門による2名承認を要する。マスキング中もすべてのイベントを通常どおり記録する。ただし suppressed=true および承認書番号を追加するだけであり、黙って破棄してはならない。リセットもボタンを押すだけの行為ではない。S3/S4では、リセット前に根本原因コード（故障辞書の項目に対応）と処置担当者を記入しなければならない。リセット後は初品標準試験片による検証を実施し、イベント発生層の上下各3層について未溶融および気孔を再確認する。4項目の記録がそろって初めてbuild隔離を解除できる。「マスキング率：buildの1%以下」「未分類イベント比率：2%以下」「同一根本原因が1時間以内に5回超繰り返された場合は根本原因調査の作業指示を自動発行」「イベント・スナップショット完全性：99%以上」を月次ダッシュボードに組み込むことを推奨する。
6. バージョン凍結と変更：ファームウェア更新後、旧コードはどこへ行くのか
コード表は統制文書であり、気軽に変更するExcelファイルではない。リリースのたびに、バージョン番号、SHA-256ハッシュ、有効日、適用対象装置のシリアル番号リスト、最低ファームウェアバージョンを生成し、パラメータパッケージバージョンおよびbuild番号との3キーで納入エビデンスチェーンに結び付けて記録する。コードの追加または改訂は変更申請を経なければならない。すなわち、影響分析（影響を受ける履歴記録、作業カード、インターロックロジック）→ 3部門レビュー → 新旧コードマッピング → 有効日での切替 → 旧作業カードの廃止、という手順である。ファームウェア更新の前後には、必ずコード表整合性比較を実施する。コントローラが実際に出力するコード番号、レベル、記述を項目ごとに確認し、現行の統制バージョンと一致するかを検証する。不一致があれば、装置の運用リリースを凍結する。履歴コード表およびイベントログの保存期間は、少なくとも製品寿命に3年を加えた期間とし、読み取り専用でアーカイブすることが望ましい。
7. 導入チェックリストとよくある誤り
30日間で導入を進められる。第1週は全コントローライベント一覧をエクスポートし、5セグメント方式で再採番してコード領域台帳を作成する。第2週は4段階動作マトリクスおよび発報条件式を完成させ、デバウンスとヒステリシス帯を追加する。第3週はイベントスナップショットの10項目と、パラメータパッケージハッシュおよび層番号との自動連携を実現する。第4週には30分間の追跡演習を実施する。3か月前のS3イベントを無作為に1件抽出し、当時のコード表バージョン、発報条件、スナップショット、リリース判断を復元する。復元成功率の目標は95%以上とする。よくある誤りは4つある。アラームコードを自然言語の記述として書き、機械可読にできないこと。閾値だけを定義し、継続時間と有効化運転状態を定義しないため、保全時の誤報が大量に発生すること。マスキング時に記録自体を行わず、事後のエビデンスチェーンを断ってしまうこと。ファームウェア更新後も旧コード表を使い続け、新旧の意味が混在することである。
まとめ
設備アラームおよびイベントコードの統制された定義は、「機械が何を言ったか」を「現場が何をすべきか」へ翻訳するための基盤エンジニアリングである。これはエネルギー消費算定、電力品質対策、予知保全、検査ロット管理に取って代わるものではなく、それらの手法に安定的で再計算可能、かつ追跡可能な入力辞書を提供する。設計、プロセス、製造から実製品の納入まで、全工程をカバーするプラットフォームにとって、すべてのコードを一意にし、各レベルの動作を一意にし、すべての例外を記録し、すべてのバージョンを凍結可能にすることで初めて、夜勤中の一つの通知を、どのシフトでも同じ結論に至る工学的事実へ変えることができる。