製造業で設備停止理由コードの管理システムを導入するなら、最初に決めるべきことは「停止をどう検知するか」と「誰が理由を確定するか」を分けることだ。PLCの停止信号は時刻と継続時間を示せても、材料待ち、段取り、品質確認、故障という業務上の原因を必ずしも確定できない。本稿は、停止理由の分類表を作り、MESで作業者が確認し、ERPの計画と突合するための導入仕様、運用、受入試験を示す。OEEの計算だけを説明する記事ではない。
設備停止理由コード管理システムで決めるべき境界
設備の監視画面に赤いランプが表示されても、「何のために止まったか」は一つの値では表せない。停止開始時に分かるのは設備状態である。アラームが同時に出れば機械が報告した事象も分かる。しかし「材料補充の遅れが先でアラームは結果」「品質確認のために作業者が意図的に止めた」という現場の文脈は、追加の確認が必要だ。停止イベント、機械アラーム、作業者が確定した停止理由、根本原因、是正処置を別のデータとして保存する。これらを一列の「原因コード」に押し込むと、後から訂正した時点で機械から来た事実まで書き換わる。
ISA-95は制御・監視側、製造オペレーション側、業務計画側の境界を整理する。実装上はPLCや設備接続層が状態変化を捕捉し、MESが生産指示・シフト・作業者確認と結び、ERPが計画や原価の文脈を渡す構成を検討できる。これはISA-95が特定製品を指定するという意味ではなく、責任の所在を決めるための参照枠だ。ISAの公式説明ではLevel 2をPLC等の監視・制御、Level 3を製造オペレーション、Level 4をERP等の事業計画に位置付ける。
設備状態の自動取得、設備停止理由の分類、停止ロスの分析は近いが異なる仕事である。OEE改善の記事は稼働率・性能・品質を使った改善の全体像を扱い、チョコ停とOEEの記事は短い停止の扱いを詳しく扱う。本稿は、その計算に入る前の理由コードの正本、確定操作、修正履歴、システムの受入条件に絞る。
「設備停止」と「停止理由」を同じ信号から作らない
停止検知の入力は、PLCの運転ビット、サイクル完了パルス、設備アラーム、モード信号、製品通過センサーなどから選ぶ。すべての設備に共通の一ビットで「生産中」を表せるとは限らない。自動運転中でも品物を待つ装置、手動操作を含む工程、連続プロセスで低速運転を許す装置では、状態の意味が違う。設備ごとに「運転」「停止」「段取り」「保全」「通信断」「判定不能」の状態遷移表を作り、誰が承認するかを決める。
イベントの最小単位は設備ID、開始時刻、終了時刻、取得元、元信号、取得品質、状態、イベントIDである。開始だけ取れて終了がない事象は「進行中」とし、勝手にシフト終了時刻で閉じない。通信断は設備停止として計上せず、別のデータ品質イベントとして表示する。PLC時刻とサーバー受信時刻は両方保存し、時刻同期の状態も残す。現場端末がオフラインになって後で同期した場合、入力時刻と事象発生時刻を混同しない。
OPC FoundationのMachine Tools仕様は、機械状態、稼働モード、停止を表すイベントを区別し、停止について条件クラスを扱う。これにより機械側から一定の分類情報を取得できる場合はある。ただし機械の警報コードをそのまま会社の停止理由コードに置き換えることはできない。たとえば「搬送モータ過負荷」は装置が見た症状であり、ワーク噛み込み、部品摩耗、誤投入のどれを業務上の理由にするかは確認が必要である。設備が理由を十分に報告しない場合もある。
開始と終了を何で判断するかは装置ごとに試験する。サイクル完了パルスが一定時間ない状態を停止と推定する場合、長サイクル品や段取り品を誤検出しない閾値が必要だ。閾値は一律の「30秒」にせず、製品・工程・モード別に検証する。誤検知を減らそうとして閾値を長くすれば短い停止が見えなくなる。したがって、元イベントと「報告対象にしたイベント」を分けて残す。後から閾値を変更しても、履歴を再計算できる設計にする。
停止理由の分類表は二段階から始める
分類が細かすぎると作業者が正しいコードを選べず、「その他」が増える。大分類は初期運用なら、設備故障、材料・部品待ち、段取り・型替え、品質確認、計画停止、上流・下流影響、外部要因、理由未確定など、現場で区別できる範囲に絞る。小分類は改善行動が分かれるときに追加する。たとえば「材料待ち」を「支給遅れ」「投入準備」「誤品」に分けるなら、それぞれの担当部署と対策が異なることを確かめる。単に集計表を詳しく見せるためだけの小分類は維持費を増やす。
コード表にはコードID、JA/TH/ENなどの表示名、説明、含める例、除外する例、親分類、適用設備・工程、有効開始日、有効終了日、責任部署、承認者を持たせる。タイ工場で日本語の分類名だけを掲示すると、現場の入力が翻訳推測になる。Thai表示は現地の班長と作業者が実際の用語で確認し、English表示は拠点をまたぐ分析に使う。ベトナム拠点へ展開する場合も同じコードIDを維持し、表示名のみローカライズすれば比較しやすい。ただし工程の意味が異なるコードは無理に共有しない。
「理由未確定」は正式なコードとして残す。入力画面で未選択を禁止し、作業者が根拠のないコードを選ぶより、未確定の件数と滞留時間を見えるようにする方がよい。未確定には担当者と期限を付け、交代時に引き継ぐ。初回入力時には「暫定理由」として登録し、保全の診断後に「確定理由」へ変わることもある。暫定値を消さず、誰が、いつ、どの証拠で変更したかを保存する。欠落を数えられるようにすることが分類品質の出発点だ。
理由分類と責任部署は同義ではない。「材料待ち」でも調達、倉庫、上流工程、供給者のどこに原因があるかは調査しないと分からない。作業者に責任部署まで即時確定させると、責任回避がコード選択を歪める。最初の画面では観察可能な事象と作業を選び、後で担当者が原因と処置を追記する。品質異常のためラインを止めた場合、最初の「停止理由」は品質確認であって、根本原因は別の不良解析に任せる。この分離は現場の入力負荷も軽くする。
停止理由コードマスターの変更を誰が承認するか
分類表は導入初日に完成しない。運用を始めると、既存コードに入らない停止や、似たコードが複数ある問題が出る。現場からの変更要望を月次で集め、生産、保全、品質、ITの代表が「既存コードの説明追加」「新コードの追加」「コードの統合」「廃止」を決める。所有者を一人または一部署に明記する。承認日と適用日を分け、古いコードで入力済みの履歴は書き換えない。
コードの追加には三つの条件を置くと管理しやすい。第一に既存コードでは改善責任を決められないこと。第二に作業者が現場で再現性よく選べること。第三に十分な件数または影響があり、別集計する価値があることだ。「月に一度しか起きないが安全に関係する事象」など、件数だけで除外してはいけない例外もある。安全関連の分類は設備安全手順と整合させ、理由コード画面が安全装置の代わりだと誤解させない。
変更を技術的に管理するため、コードIDは表示名の翻訳や組織変更から独立させる。廃止後も履歴参照できるよう論理削除にし、開始日・終了日で有効性を判定する。親分類を変えた場合、過去レポートを当時の分類で見るか、現在の分類へ再集計するかを利用者に示す。両方を混ぜて前年対比を作ると、改善したように見えて分類変更だけだったという誤読が起こる。コード変更履歴と集計版をダッシュボードにも表示する。
作業者がMESで理由を確定する業務フロー
停止が発生した瞬間に入力を強制する運用は、安全確認や設備復旧の邪魔になる。まず機械が停止イベントを発行し、HMIまたは現場タブレットに未確定キューを作る。作業者は安全を確保して復旧を優先し、許容した時間内に理由を確認する。画面には設備、時間帯、作業指示、機械アラーム、直前の状態、候補理由を表示する。候補は便利だが自動確定にしない。確認ボタンを押した人、日時、選択コード、自由記述、証拠を残す。
交代間際に発生した停止は、発生シフトと確認シフトを分ける。夜勤終了時に未確定が三件あれば、班長が三件を一括して適当な理由にするのではなく、担当、一次情報、確認期限を次の班へ渡す。交代帳票には「未確定イベントID」「設備」「継続中か終了済みか」「暫定理由」「確認者」「期限」を表示する。シフトをまたいで一つの停止が続いた場合、イベントをシフト境界で分割しても親イベントIDを残し、開始から終了までの実時間が二重計上されないようにする。
例を挙げる。充填ラインが10:12に停止し、PLCはコンベヤ過負荷を出した。作業者はガイド部のワーク詰まりを取り除き、10:20に再起動した。MESには8分の停止イベントが自動登録され、作業者が「ワーク詰まり」を選ぶ。保全が後日、ガイドの摩耗を根本原因として登録し、交換作業を紐付ける。「過負荷」というアラーム、「ワーク詰まり」という現場理由、「ガイド摩耗」という根本原因は同じではない。この三つを混ぜないから、現場の停止傾向と保全の故障分析を両立できる。時刻と数値は説明用の架空例であり、標準的な停止時間を意味しない。
確認の期限は全設備に一律に課さない。停止時間や損失が大きい設備ならシフト内確定を目標にし、微小停止は集合レビューでよい場合がある。ただし後から記憶に頼るほど分類精度は落ちる。重要な停止はイベント後に入力する人が特定できるようにし、未確定のまま統計へ入る場合は「未確定」と明示する。入力が遅れた比率、変更された比率、その他・未確定の比率を分類品質のKPIにする。
PLC・MES・ERPの接続は正本と責任を分ける
PLC・設備ゲートウェイからは機械状態、時刻、設備ID、アラームID、運転モード、サイクル情報を取得する。MESは停止イベントIDを発行し、生産指示、製品、ロット、作業者、シフト、理由コードと関連付ける。ERPは製造指示、計画稼働時間、品目、コストセンターなどの参照情報を提供する。ERPに分単位の停止イベントを全部複製する必要はない。管理会計や計画修正に使う確定済みの集計を渡すこともできる。どの粒度を連携するかはERP側の処理能力と利用目的で決める。
インターフェース仕様には方向、頻度、主キー、タイムゾーン、再送時の重複排除、欠損時の扱い、訂正時の扱いを明記する。同じPLCイベントが再送されたら二重の停止を作らず、同一イベントIDとして上書きまたは追記する。MESで理由を変えた場合は「最新版」だけをERPへ送るのか、取消・再計上を送るのかを決める。通信が切れてから復旧したときにイベントが時系列で逆転することも想定する。保存順と発生順は別の列にする。
ISOのISO 22400-2は製造オペレーション管理におけるKPIと時間要素を定義する。導入側はこの定義を参考に、「計画稼働時間」「実稼働時間」「停止時間」の母数を契約仕様に固定する。昼休み、計画保全、段取り、材料待ちをどこへ入れるかは工場のルールに依存する。理由コード表だけを揃えても時間モデルが違えば、拠点間の停止率は比べられない。設定画面に計画停止区分と集計式の版を表示する。
NISTの製造データの追跡可能性に関する勧告は、製造関連データの出所と信頼性を保持する考え方を示す。対象工程は限定されており、このブログの分類表がNISTの標準仕様だという意味ではない。しかし停止イベントを誰がいつ訂正したか、元の機械信号が何だったかを残す設計判断の参考になる。監査ログを残すだけでなく、現場の画面で「自動検知」「作業者確認」「保全確定」の状態を見分けられるようにする。
微小停止と重複イベントをどう扱うか
数秒のチョコ停を一件ずつ作業者に入力させると、入力自体が生産を妨げる。だが消してしまうと改善の対象が消える。元イベントは保存し、画面上の入力対象を閾値で絞る。短い停止は同じ設備・同じ状態・近い時刻でまとめ、シフトレビューで代表理由を付ける運用がある。ただし、その理由が個々の停止で本当に同じだったと断定しない。「集約理由」と「個別確定理由」を区別する。入力閾値と集約閾値を変えた日付を残し、前年比較は同じルールで再計算する。
一台が止まったことで後工程が止まる場合、各設備の停止時間を単純合計してライン損失と呼んではいけない。各設備イベントには独立したIDを与え、ライン全体の停止区間は重なりを除いて計算する。原因設備が分かる場合は親子関係を登録するが、推定であれば推定と表示する。下流設備の「上流待ち」は現場理由として正しくても、上流設備の故障と同一の損失として二重計上する集計は別物だ。管理画面で設備別時間とライン別時間を混同しない。
アラームが一秒間に何件も出る設備もある。一つの停止に複数のアラームを紐付け、最初に発生したもの、停止中に発生したもの、復旧直前に発生したものを区別する。最初のアラームが根本原因とは限らない。システムの候補提示は「参考信号」と明示し、確定理由は作業者または承認者が選ぶ。原因推定にAIを使う場合でも、提示理由の採用率と訂正率を測り、誤った自動分類が改善会議の数字に混ざらないようにする。
導入前の現場調査で集めるもの
RFPを書く前に、一ラインの現物を確認する。設備一覧、PLC機種と接続可否、現在の信号表、アラーム一覧、サイクルタイムの幅、品目切替方法、シフトカレンダー、生産指示の付け方、紙の日報、保全記録、既存のOEE集計を集める。現場で典型的な停止を5〜10例ほど選び、「機械が何を出したか」「作業者が何を見たか」「今の帳票に何と書くか」「誰が対策したか」を追う。件数は調査の実務上の目安であり、統計的な標本数ではない。
信号が足りない場合は後付けセンサーを検討できるが、理由コードの不足をセンサーだけで埋めようとしない。センサーは状態変化を増やすが、材料待ちと段取りの区別を単独で決められないことがある。逆に、機械の停止時刻を紙の日報から推定する運用では秒単位の精度を求めても意味がない。接続できる設備とできない設備の違いを記録し、手動入力を許す設備は「手入力」の取得元を明示する。
調査では班ごとの言葉も確認する。同じ「材料待ち」が、夜勤では段取り待ち、日勤では倉庫待ちを意味するなら、コード一覧を統一する前に説明文と事例を揃える。タイ語の表現は現場で使う短い語にし、管理者向けの英訳と一対一対応するようレビューする。作業者に操作を見せてもらい、停止後に何タップで入力できるか、手袋をしたまま使えるか、再起動時に入力画面が作業を遮らないかを確かめる。
RFPに入れるべき機能・非機能要件
RFPには「OEEが見えるシステム」だけでなく、停止イベントから理由確定までの受入可能な動作を書く。最低限、設備状態の自動取込、手動イベント登録、未確定キュー、理由コードの有効日管理、権限別の確認・訂正、機械アラームとの並列表示、シフト引継ぎ、監査履歴、設備別とライン別の集計を分けて要求する。複数言語UIが必要ならコードの表示名、説明、自由記述の扱いまで指定する。多言語画面だけあってコード説明が日本語だけでは現場運用にならない。
非機能要件は画面速度だけではない。PLC通信断と復旧、端末オフライン、イベントの再送、時計ずれ、権限失効、バックアップ復元、ログ保管期間、セキュリティ境界、設備増設時の設定追加を確認する。イベントから画面表示までの遅延許容値は現場の意思決定に合わせて決める。数秒の遅れが許されない安全機能をMESへ移すべきではない。理由確認の画面は生産管理用途であり、安全停止回路や設備インターロックから独立させる。
発注側とベンダーで責任分担表を作る。PLCタグの意味を誰が確認するか、設備改造を誰が承認するか、コード表を誰が整備するか、ERPの製造指示IDを誰が提供するか、データ移行と過去帳票の照合を誰が行うかを明記する。試験で「仕様どおりだが現場が使えない」となるのは、画面だけをベンダーの責任とし、運用定義を誰も持たないときだ。RFPにはサンプル停止事例を添え、候補製品に同じ事例を操作デモで再現してもらう。
| 要求項目 | 発注前に決める問い | 受入時の証拠 |
|---|---|---|
| 停止検知 | どの信号・モードを対象にするか | 信号波形とイベント時刻の照合 |
| 理由確定 | 誰がいつ暫定・確定を入力するか | 操作ログと変更履歴 |
| コード管理 | 追加・廃止・翻訳を誰が承認するか | 版と有効日の再現 |
| 集計 | 設備・ライン・シフトの母数は何か | 手計算との突合 |
| 連携 | ERP/MES間のキーと訂正方法は何か | 再送・取消の試験ログ |
| 例外 | 通信断や未確定をどう見せるか | 異常ケースの画面と出力 |
FAT・SATでは正常系より例外系を先に試す
工場出荷前のFATでは模擬PLCイベントとサンプルの生産指示を使い、仕様どおり停止開始・終了、アラーム紐付け、理由選択、訂正履歴、レポートが出るかを確認する。現地のSATでは実設備と実シフトを使い、時計、ネットワーク、端末配置、作業者の操作を確認する。ISAのISA-105案内は産業自動化のFAT、SAT、SITを扱う枠組みを紹介する。ただし、その案内はMESの停止理由分類の完成基準を定めるものではないため、本稿の試験項目は導入実務の提案として読む。
例外系は少なくとも、同一イベントの再送、通信断後の遅延着信、停止中のシフト交代、停止中の生産指示切替、アラーム多発、理由未確定、廃止コードの選択防止、理由訂正、手動イベントと自動イベントの重複、サーバー時計ずれを含める。試験担当者が再現手順、入力、期待結果、実結果を一行ずつ記録する。「画面が開いた」だけを合格条件にしない。
受入数値はサイトごとに決める。たとえば一ラインの対象設備で手元の停止ログとシステム記録を突合し、重要な停止イベントの取りこぼしゼロ、理由未確定の件数が日報と一致、イベント時刻差が合意した許容範囲内、という条件を設定する。ここに示した「ゼロ」は契約上の目標例であって一般規格の要求値ではない。必要な精度は工程のサイクルと改善会議の単位によって変わる。停止理由の正解率を測る場合、比較の正本となる観察記録を事前に決める。
本番移行は一ライン、一シフトから始め、紙の日報と並走期間を設ける。両者の差は「システムが間違い」と決めつけず、日報の丸め、シフト時刻、計画停止の除外、入力遅れのどれかを調べる。差分の一覧を毎日レビューし、コード表の修正、信号条件の調整、作業者説明の改善を切り分ける。並走終了条件は、理由未確定の滞留、重大停止の取りこぼし、集計値の説明可能性、班長の承認を組み合わせる。
費用対効果は「停止時間が減るはず」で見積もらない
導入費用には、設備接続、MES設定、現場端末、ネットワーク、コード表整備、ERP連携、試験、教育、保守を入れる。運用費用にはコードの改訂、端末交換、設備追加、問い合わせ対応、データ品質レビューがある。既存の設備監視基盤が使えれば初期費用は変わるため、設備台数だけで市場価格を断定できない。RFPではライセンス、接続点、端末、シフト、保存年数、追加設備の単価を分けて見積もらせる。
効果は「分類できた停止のうち、実際に対策し、再発が減った時間」で評価する。停止理由コードの導入自体は設備を直さない。仮に月100時間の停止が記録され、うち30時間が未確定、対策可能と判定できるのが20時間、そのうち実際に減らせたのが5時間なら、見積りの便益は100時間でも20時間でもなく、確認できた5時間を基準にする。この数値は説明用の架空例である。ライン能力、後工程の制約、需要、時間当たりの限界利益に応じて経済価値は変わる。停止時間が減っても出荷増につながらない場合、残業や外注費の減少など別の便益で見る。
導入後は停止時間だけでなく、理由確定率、未確定の経過時間、その他コード比率、コード変更件数、停止イベントと日報の一致率、改善施策の完了率を月次で追う。理由確定率が高くても全員が「設備故障」を選んでいれば意味がない。分類の粒度と現場負荷を一緒に見て、必要なときに表とUIを直す。改善会議で使わない詳細コードは減らしてよい。
理由コードの割当ルールを事例で検証する
分類表をレビューするときは、名称の一覧だけで合意しない。実際の停止事例を読み、別の班長が同じコードを選ぶかを試す。「コンベヤ停止」を機械停止として一括りにしたい人と、搬送詰まり、前工程待ち、製品なし、品質保留を分けたい人では目的が違う。コード説明には何が観察できたら選ぶかを書く。設備故障を選ぶ条件は、単に機械が動かなかったことではなく、故障・異常が確認されたことにする。診断前は「理由未確定」または観察可能な現象を選ぶ方が、後の故障件数を過大評価しにくい。
境界事例を五つほど用意する。第一に材料が届かず設備がアイドルになった事例。第二に材料はあるが品質判定待ちで加工できなかった事例。第三にサイクル中の異常アラームで止まったが、復旧操作だけで再開した事例。第四に設備は動けるが後工程の満杯で止めた事例。第五に予定した型替えが長引いた事例だ。停止の検知ルールと理由の選択ルールを分けて採点する。複数の人が同じ判断になることが重要で、分類数を増やしても一致率が下がれば集計の信頼性は落ちる。
長い停止の間に理由が変わることもある。材料待ちで始まり、材料到着後に設備故障が分かったなら、二つの区間として分割するか、主理由と副理由を管理するかを決める。作業者が後から便利な方を一つ選ぶと、材料待ち時間か設備故障時間のどちらかが消える。ただし区間を細かく分けすぎると時刻の根拠が失われる。証拠となる材料搬入記録や保全連絡の時刻があるときだけ分割し、不明な区間は未確定として残す。報告書では時間が推定か確認済みかを区別する。
「計画停止」と「故障」は理由コードの階層だけで決まらない。設備を止める予定が生産計画に登録されていたか、予定より早く始まったか、予定終了後に延びたかで扱いが変わる。計画保全が予定より二時間長引いたなら、予定部分と超過部分の扱いを定義する。OEEの可用率から除く時間と、経営会議で見る停止時間が異なることもある。その場合はレポート名と母数を明示し、同じ「停止ロス」の名称で異なる数字を並べない。
設備メーカーのアラーム番号はファームウェア更新で変わる可能性がある。MES側の理由コードをアラーム番号と一対一で結び付けるなら、機種、ファームウェア版、対象設備、適用開始日をマッピング表に持つ。新しいアラームを未分類に落とす仕組みも要る。現場の人が理由を確定したら、どの候補が選ばれたかを記録し、候補提示の精度を定期的に確認する。候補が頻繁に外れる場合は、アラームと理由が本質的に別物なのか、マッピングが古いのかを調べる。
シフト、工場、言語をまたぐ集計の落とし穴
停止イベントに時刻があっても、シフト割当が一意とは限らない。日をまたぐ夜勤、休日出勤、臨時シフト、設備の早出運転がある。ERPのカレンダー、MESの実績シフト、勤怠のシフトは目的が異なる。停止の発生時刻をもとに実績シフトを判定し、後からシフト表が修正されたときに過去のレポートを再計算するかを決める。レポートには集計日時とカレンダー版を表示する。海外本社向けにUTCへ換算するときは、タイ工場の現地日付を失わないよう、イベント時刻と工場タイムゾーンを保存する。
複数工場の比較では、同じ親コードでも現場の適用範囲がずれていることがある。ある工場は「段取り」に清掃を含め、別工場は計画停止に含めるなら、停止時間の割合に差が出ても改善力の差とはいえない。比較可能な共通コードと、拠点固有コードを分け、共有する指標の集計式を統一する。拠点固有コードは共通親分類へ対応付けられるようにするが、現場の事情を無理に消さない。コード対応表の有効期間を管理し、拠点が変更したら報告側にも通知する。
翻訳の問題は単語の置換だけではない。日本語の「チョコ停」をThaiやVietnameseへ直訳しても、現場の作業者に意味が伝わるとは限らない。UIには短い名称と具体例を併記し、よくある設備停止の写真や標準作業を教育資料として参照できるようにする。自由記述を全て英語に統一すると入力の質が下がる場合は現地語で受け付け、分析用のコードIDを共通にする。翻訳案は現地の班長が実際の停止例を使って確認する。IT担当者だけで承認すると、画面上は整っていても選ばれない分類になる。
班長の権限で理由を修正するとき、元の作業者の入力を消さない。「作業者入力」「班長承認」「保全による根本原因」の三段階が必要な設備だけを対象にする。全ての短い停止で三人の承認を要求すれば滞留が増える。重大度、停止長、顧客影響に応じて承認レベルを変える。修正が多い分類は作業者を責めるのではなく、コード名が曖昧、候補提示が不適切、確認に必要な情報が表示されていない可能性を調べる。
導入後の改善会議に必要な画面と意思決定
ダッシュボードに「停止理由トップ10」を出すだけでは、改善は進まない。一件ごとに設備、製品、指示、シフト、発生時間、理由確定状態、アラーム、処置をたどれるようにする。件数が多い短い停止と、件数が少ない長時間停止を別に見る。合計時間、発生頻度、平均時間の三つを並べれば、部品交換が必要な長い故障と、調整で繰り返す短い詰まりを区別しやすい。月次会議では理由コードの順位だけでなく、前月の対策後に対象停止がどう変わったかを確認する。
改善アクションには担当、期限、確認する指標、対象設備、変更内容、実施日を結び付ける。たとえば「ガイド調整後にワーク詰まりの件数と時間が減るか」を追う。製品構成や稼働時間が変わると生の停止時間だけでは比較しにくいため、同じ稼働条件のシフトや単位生産時間当たりでも見る。対策後に停止が減っても、理由が別コードへ移っただけなら効果とみなさない。コード改訂履歴、工程変更、設備の保全履歴を一緒に参照する。
現場に返す画面は会議用の大型グラフと別に考える。作業者には「今、確認すべき停止」「候補の根拠」「前シフトからの引継ぎ」が必要だ。班長には未確定件数と滞留理由、保全にはアラームと再発履歴、管理者には改善アクションの進捗が必要になる。一画面に全情報を詰め込まず、それぞれの役割で次に取る行動を見せる。導入後に入力が続かない場合、作業者の意識ではなく、復旧作業とUIの順番が合っているかを確認する。
導入判断のためのチェックリスト
- 対象設備と「停止」の定義が、運転モード・品目・シフトを含めて合意されているか。
- 機械状態、アラーム、作業者の理由、根本原因、処置を別に保存できるか。
- 理由未確定を隠さず、担当と期限を付けて引き継げるか。
- 理由コードの所有者、変更承認者、有効日、翻訳レビュー者が決まっているか。
- 設備ID、製造指示ID、シフトID、イベントIDの連携キーが定義されているか。
- 短い停止、重複信号、通信断、シフトまたぎの集計ルールがあるか。
- FATとSATで現場の異常ケースを再現し、証拠を残せるか。
- 停止分類から改善施策までの担当と会議体が決まっているか。
まとめ
製造業の設備停止理由コード管理システムは、停止信号を集めるだけでは機能しない。PLCが示す状態、作業者が確認した理由、保全が調べた原因を分け、コード表の変更を統制し、未確定を見えるようにする。MESはその確認と引継ぎの場になり、ERPは計画や業務の文脈を提供する。RFPに例外ケースと受入条件を入れ、一ラインで日報との違いを説明できるようにしてから広げると、停止ロスの分析に使えるデータになる。
TOMAS TECHでは、設備信号の確認、停止理由コード表の設計、現場入力フロー、MES/ERP連携、FAT・SATの試験項目を一緒に整理できます。構想やRFPの準備段階でも、お問い合わせから対象ラインと現在の日報運用をお知らせください。
よくある質問
設備停止理由コードは何種類から始めるべきですか？
全工場共通の正解はない。まず大分類を現場で見分けられる数に絞り、小分類は担当と改善行動が変わる場合に追加する。その他・未確定が多いかを運用開始後に測り、コードを増やす前に説明文と教育を見直す。
PLCのアラームコードをそのまま停止理由として使えますか？
機械が示す症状と業務上の理由が一致すると確認できる場合には候補として使える。しかし、アラームが結果である場合、材料待ちや品質確認を示さない場合がある。元アラームを保存し、確定理由は別項目で管理する。
ダウンタイム理由コードの未確定をゼロにすべきですか？
数値をゼロにするための推測入力は避ける。未確定を正式な状態として表示し、担当と期限を設定する。発生後すぐの暫定理由と調査後の確定理由を区別すれば、事実の欠落と調査中を分けられる。
OEEの停止ロスと理由別停止時間は同じですか？
必ずしも同じではない。OEEには計画稼働時間と除外時間の定義がある。理由別停止時間は元イベントの時間を分類したものなので、計画停止、チョコ停、ライン重複などの扱いを合わせて初めて比較できる。
MESを入れずに停止理由を管理できますか？
小規模なら既存の日報や設備監視システムで始められる。ただし作業者確認、変更履歴、シフト引継ぎ、ERPの製造指示との紐付けが必要になると、MES相当の機能が要る。製品名より必要な業務機能で判断する。
FAT・SATで最優先に試すことは何ですか？
正常な一件だけではなく、再送、通信断、シフト交代、理由訂正、廃止コード、手入力と自動入力の重複を試す。実際の受入基準は対象設備とサイクルから合意し、入力と期待結果を記録する。
参考情報
- ISA, ISA-95 Standard: https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- ISA, ISA-95 operations event overview: https://www.isa.org/intech-home/2017/november-december/features/isa-95-to-support-smart-manufacturing-iiot
- OPC Foundation, OPC UA for Machine Tools Part 1: https://reference.opcfoundation.org/specs/OPC-40501-1/full
- OPC Foundation, InterruptionConditionType: https://reference.opcfoundation.org/MachineTool/v101/docs/9.2
- ISO, ISO 22400-2 KPI definitions: https://www.iso.org/obp/ui/?_escaped_fragment_=iso%253Astd%253A54497%253Aen
- NIST, Recommendations on Ensuring Traceability and Trustworthiness of Manufacturing-Related Data: https://www.nist.gov/publications/recommendations-ensuring-traceability-and-trustworthiness-manufacturing-related-data
- ISA, ISA-105 FAT/SAT/SIT overview: https://www.isa.org/standards-and-publications/isa-standards/isa-105-standards
