生産実績の自動収集を導入したいとき、最初に買うべきものは端末でも通信ソフトでもありません。先に「何を実績と呼び、どの製造指示・ロットに帰属させ、どの時点で確定するか」を決めます。PLCのカウンターだけを取得しても、品番切替、段取り、手直し、不良、通信断を説明できなければ、ERPへ渡せる実績にはなりません。本記事はタイ工場の購買・生産技術・現場・ITが共同で使える、要件定義からRFP、FAT、SATまでの実務手順です。
結論:収集対象は「数」ではなく、出所と帰属が分かる実績イベント
製品が一つ通過したという信号は、重要ですが、それ自体は完成実績ではありません。その時にどの製造指示が有効だったか、良品か不良品か、どの設備・工程で、誰の確認を経て記録されたかがそろって初めて、進捗や在庫に使える情報になります。逆に、すべてをセンサーで自動化する必要もありません。設備が確実に知る通過数はPLCから、設備が知らない不良理由や手直し区分は作業員が端末で選ぶ、という役割分担の方が監査と運用に強いことがあります。
導入時には次の五つを一組で定義します。第一に実績の粒度、第二に製造指示・ロットへの紐付け、第三に通信断時の保存と再送、第四にMESまたは生産管理システムでの照合・承認、第五にERPへの確定値の連携です。提案書の機能一覧より、実際の生産シナリオを流した時にこの一連の経路が閉じるかを評価してください。ISA-95は製造オペレーションと企業システムの境界を整理する参照枠組みであり、PLC・MES・ERPの役割を議論する共通語として使えます。ISAのISA-95解説を参照してください。

生産実績を何に使うかで、取るべきデータは変わる
「実績を見える化したい」だけでは、見積範囲が定まりません。日次進捗を把握するなら工程と指示ごとの良品数・不良数・時刻が必要です。仕掛を追うなら投入と完了の両方が必要です。製品原価まで反映するなら、材料払出、作業時間、手直し、廃棄の帰属も問題になります。品質の証跡まで求めるなら、検査結果、計測機器、判定版数、訂正履歴が加わります。設備稼働率の把握だけを目的にしたランタイム監視とは、同じPLCを読んでもデータモデルが異なります。
関係者ごとに「使う画面・判断・許容遅延」を一行で書き出してください。現場班長は指示ごとの不足数を交代前に知りたいかもしれません。生産管理は翌朝の計画変更に使いたいかもしれません。経理は月締め時に確定済み数量しか受け取りたくないでしょう。ここを混ぜると、速報値を確定値としてERPに送ったり、確定待ちのために現場画面が遅れたりします。速報イベント、照合済み実績、会計・在庫反映済み実績の状態を分けて設計します。
| 利用目的 | 最小の記録 | 欠けると起きること | 主な受け手 |
|---|---|---|---|
| 指示別進捗 | 指示、工程、設備、良品数、時刻 | 別指示の数量を合算する | 現場・生産管理 |
| ロット別追跡 | 指示、投入ロット、完成ロット、工程、時刻 | ロットの履歴を再現できない | 品質・倉庫 |
| 在庫反映 | 確定数量、単位、保管先、取消・訂正 | 二重計上や負在庫を招く | ERP・倉庫 |
| 原価分析 | 数量、作業時間、材料、手直し、廃棄理由 | 差異が設備や製品に帰属しない | 経理・管理者 |
この表は実装範囲を考えるための例であり、すべての工場に同じ項目を強制するものではありません。自社の運用目的を一つ選んで最小構成を決め、そこから拡張します。生産管理システムとMES、ERPの基本的な役割を整理したい場合は、生産管理システムの全体像も参考になります。
現状調査では、設備の信号より先に「指示切替」を観察する
設備一覧を作る際は、メーカー・機種・PLC型式・通信口だけでなく、工程、製品切替の頻度、金型・治具、通過品の単位、排出位置、手直し戻り、作業員の端末位置を記録します。良品カウンターがあるか、カウンターがリセットされる条件は何か、停電や設備交換で値がどうなるかも確認します。設備側のアドレスやタグ名を見ただけでは意味を確定できません。現場で一個を流し、信号がいつ立ち、いつ戻り、実物がどこにあるかを対比する必要があります。
特に製造指示の切替方法が重要です。手書き札を変えるだけなのか、バーコードを読んで端末で開始するのか、PLCのレシピ変更と連動するのか。指示切替の時刻が曖昧なら、境界付近のカウントは必ず誤帰属します。ここは「前の指示に含める」「いったん未割当として保留する」「責任者が承認する」といったルールを合意し、例外としてログに残します。現場の暗黙の判断をそのままソフトに移すと、見える化した後も数字が合わない理由を説明できません。
調査対象には通常運転だけでなく、段取り替え、試作、機械停止、夜勤、休憩、二人作業、複数指示の混流を含めます。古い機械には信号を取り出せないものもあります。その場合は後付けセンサーが妥当か、簡潔な端末入力にするかを安全性と保守性で選びます。信号を取るために既存の制御プログラムを書き換える案は、設備保証と停止リスクを見積りに含めて評価します。
PLCカウンターを「生産数量」に読み替える前の確認事項
PLCの累積カウンターを一定間隔で読む方式は、信号パルスを毎回クラウドへ送る方式より扱いやすい場合があります。ただし単純な差分計算は危険です。カウンターの桁あふれ、手動リセット、設備再起動、通信欠落、同じ値の再読込をどう識別するかを決めなければなりません。工程入口の検知を良品完成として数えることもできません。どの物理位置の信号を数量の根拠にするか、図面と実物で合わせます。
収集イベントには、設備ID、タグID、設備側時刻またはゲートウェイ受信時刻、読取値、品質フラグ、収集方法、通信状態、元データの識別子を残します。設備時計が信用できない場合は受信時刻も併記し、表示時刻のタイムゾーンを明確にします。タイ工場と日本本社でデータを見るなら、保存時刻を共通基準で管理し、画面では現地時刻へ変換する方が混乱を減らせます。サンプリング周期は「早いほどよい」ではなく、必要な意思決定の遅延、設備負荷、通信容量、欠落許容度から決めます。
OPC UAはセンサー、制御システム、MES、ERPなどにまたがる情報交換のためのモデルを規定します。ただし「OPC UA対応」と書かれた見積だけで、必要なタグが公開されること、データの意味が一致すること、証明書運用まで済むことは保証されません。接続可否と公開タグ、アクセス権、時刻、再接続の挙動を実機または模擬装置で確認します。OPC Foundationの仕様概説とセキュリティモデルが設計時の参照になります。
自動入力と作業員入力は、責任の違いで分ける
センサーは通過や稼働をよく捉えますが、「なぜ不良としたか」「どのロットを投入したか」「誰が再検査を承認したか」を自動で判断するわけではありません。一方、作業員に全数を手入力させれば、忙しい時間帯の入力漏れと後追い転記が残ります。したがって、自動取得項目と人が確認する項目を一つのイベントに統合する設計が必要です。端末にはいま有効な指示、品番、工程、直近の自動カウント、未確定件数を表示し、選択肢は工場の言語に合わせて短くします。
作業者IDは責任追及のためだけではありません。訂正理由や承認権限を扱い、同じ人が作業と承認を兼ねない設計が必要な工程を識別するためです。ただし、画面を開くたびに長いパスワードを要求する運用は現場で破綻します。カード、端末のセッション、交代時のログアウト、共用端末の扱いを現地の安全衛生ルールに合わせて設計します。入力できない状態を隠すより、端末がオフラインなら明示し、保存済み・送信待ち・エラーを区別して見せる方が信頼を得られます。

指示・ロットへの帰属は「後で結合」ではなく収集時に決める
実績イベントを保存してから、あとで時刻だけで製造指示に結び付ける方法は、指示切替や夜勤を挟むと弱くなります。収集時に指示ID、工程ID、設備ID、製品ID、必要な場合は投入ロットと完成ロットを固定します。設備側が指示IDを持たないなら、現場端末で開始・停止を記録し、その有効期間と設備IDから自動カウントを関連付けます。この関連付けも、競合した指示や空白期間では自動決定せず、未割当キューで扱います。
識別子は表示名ではなく不変のキーを使います。品名の翻訳、品番の表記変更、ERP側マスタ修正があっても過去実績を読み直せるためです。指示の版数、BOMや工程ルートの版数をいつ確定するかも決めます。工程完了の後でマスタを上書きし、当時の条件を再現できなくなる設計は避けます。バーコードやQRコードを使うなら、読み取った値をそのまま信用せず、該当指示が有効で、工程順序と材料ロットが許容されるかを検証します。
ロット帰属はトレーサビリティだけの話ではありません。あるロットだけ歩留まりが悪いとき、機械条件、投入原料、作業時間帯を結び付けて調べる基盤になります。ただし全ての材料を個体単位で追うと負担が過大な場合があります。出荷先の要求、回収時の範囲、品質リスクに応じて粒度を決めます。目的と費用の境界は、MES導入費用とERPとの役割分担を併せて読むと整理しやすくなります。
通信断・再送・重複を想定して初めて「自動収集」になる
工場ネットワークは停電、配線工事、無線混雑、設備保全などで途切れます。オフライン時に現場端末やゲートウェイがどのデータをどれだけ保持するか、保存容量が限界に達したら何を止めるか、復旧後にどの順序で再送するかを明記します。「ネットワークが戻れば同期する」だけでは検収できません。最低限、ローカル保存が完了したことを画面・ログで確認でき、送信済みになった後も同じイベントを再送した時に二重計上しない仕組みが必要です。
再送の鍵はイベントIDと冪等処理です。同じイベントIDを二度受け取っても、MESの実績は一度だけ反映する。一方、後から訂正が必要なら元イベントを消して上書きせず、訂正イベントを関係付けて記録する。このような境界はRFPで言葉にしておくべきです。MQTTを使う構成なら、トピック名や接続の生存状態まで標準化するSparkplugという選択肢もあります。ただしSparkplug採用が、工場固有の指示・ロット帰属や永続化設計を自動で解決するわけではありません。Eclipse Foundationの仕様概要を参照してください。
オフライン試験では、端末で未送信実績を作り、ネットワークを切り、さらに機器を再起動し、復旧後に実績とログを照合します。二重送信、順序逆転、遅延到着、時計ずれ、同一指示の終了後に届くイベントまで扱います。受信順と発生順が違うとき、過去の確定値を自動で書き換えるのか、例外として承認待ちにするのかを合意します。ここを現場立会い前に決めておけば、SATで議論が曖昧になりません。
MES・ERPへの照合は、送信成功と業務確定を分ける
ゲートウェイがHTTP 200を受け取ったことは、ERPの在庫が正しいことを意味しません。現場の生データをMESまたは生産管理システムで検証し、指示の有効性、数量単位、工程順序、重複、許容範囲を確認します。例外は担当者が根拠を見て訂正・承認します。その後に確定実績をERPに送ります。どのシステムが数の正本で、どこまでが読み取り専用の複製かを一つずつ定めてください。
照合対象は少なくとも三つあります。物理カウンターと収集イベント、収集イベントとMESの指示別実績、MESの確定実績とERPの在庫・原価反映です。差異が出た時は、件数を合わせるだけでなく、該当イベントにたどれることが重要です。夜間バッチの合計が同じでも、ロットが入れ替わっていれば正しいとは言えません。日次照合の責任者、差異が閉じるまでの期限、訂正の権限、再送の手順を運用設計に入れます。
ISA-95のLevel 3とLevel 4の整理は、MES側の製造オペレーションとERP側の事業管理を分ける議論に役立ちます。ただし個々の工場で何をどちらに置くかは、既存システムの実装と責任者に依存します。「MES導入=全てMESへ移管」と見なさず、マスタ、指示、実績、在庫の責任表を作ることが現実的です。既存製品の機能で境界を表せないなら、生産管理システムのカスタム開発の検討点も役に立ちます。
証跡品質を要件に入れる:数値だけでは説明責任を果たせない
後から「なぜその数になったか」を説明できるように、元信号と処理後の値を分けて保存します。元信号には取得元、受信時刻、状態、品質、通信履歴を付けます。処理には変換ルールの版、指示への紐付け、除外・補正・承認を付けます。結果には確定時刻、ERP送信ID、応答、再送履歴を付けます。すべてを永遠に保持する必要はありませんが、保存期間と削除方法を決めずに稼働開始すると、後で品質照会や監査要求が来た時に困ります。
時刻は特に注意が必要です。設備時刻、ゲートウェイ時刻、MESサーバー時刻が違うと、同じ一個の製品が別のシフトに入ることがあります。タイ現地の交代時刻と日付境界、サマータイムのないタイと海外拠点の時差を画面・APIで整理します。原則として発生時刻と受信時刻の両方を保持し、どちらを集計に使うか定義します。シフトは単なる日付ではなく、工場カレンダーの識別子として扱う方が再計算しやすくなります。
監査ログは管理者だけに見せればよいわけではありません。現場で値を訂正した人が、変更前・変更後・理由・承認状態を確認できることも重要です。削除で整合を取る仕組みは、再発防止の材料を消します。試運転や教育用のイベントは本番実績と区別します。これらの証跡要件は業界法規に応じて調整すべきであり、特定規制への適合を本記事だけで保証するものではありません。
RFPには「接続点数」より受入シナリオを先に書く
見積依頼書に設備台数と画面数だけを書くと、各社は異なる前提で価格を出します。比較を可能にするには、対象ライン・設備・PLC、取得タグと意味、指示切替、ロット紐付け、手入力、通信断、MES/ERP連携、訂正、保守を同じ粒度で記述します。付録として現場写真、ネットワーク図、既存API仕様、マスタ一覧、サンプルデータを渡します。ただし制御ネットワークの詳細は秘密情報として扱い、必要な範囲に限ります。
RFPの中心には受入シナリオを置きます。通常生産、一時停止、指示切替、不良発生、手直し、通信断、端末再起動、ERP受信エラー、後日訂正を具体的に書き、「入力」「期待するイベント」「画面表示」「確定条件」「ERP側の結果」を列にします。入札者には、標準機能・設定・追加開発・設備改造のどれで実現するか、未対応時の代案と費用を記入してもらいます。「可能です」という口頭回答だけでは契約範囲にしないことが大切です。
| RFP項目 | 記載する質問 | 提案書で求める証拠 |
|---|---|---|
| 設備接続 | 指定PLCから必要タグを読めるか | 実機検証結果、タグ表、権限条件 |
| 帰属 | 切替境界の数量をどう扱うか | 状態遷移図、未割当処理例 |
| オフライン | 断線・再起動時に何を保持するか | 保持容量、再送順序、重複防止方式 |
| 統合 | MES/ERPの正本と更新時点は何か | API項目、エラー時の再処理 |
| 証跡 | 訂正の前後を追跡できるか | 監査ログ例、権限表 |
| 保守 | 設備追加やタグ変更を誰が行うか | 手順書、契約範囲、復旧時間の定義 |
費用はソフトウェアだけでなく、信号取出し、ゲートウェイ、端末、配線、ネットワーク分離、API改修、データ移行、教育、立会い、保守まで分解します。タイ現地での工事は停止可能時間と安全手続きを見積条件に入れます。予備品やベンダー保守の所在も確認してください。BOIはタイの製造・サービス業の効率改善を対象とするSmart and Sustainable Industryの制度情報を公表していますが、適用条件は案件ごとに確認が必要です。BOIの現行案内を確認してから投資計画へ反映してください。
FATは模擬信号で論理を壊し、SATは工場で運用を確かめる
FAT(工場受入試験)は供給者側の環境で、接続器やMESのロジックが仕様通りかを確かめます。模擬PLCや保存済み信号列を使い、通常カウントだけでなくリセット、桁あふれ、遅延到着、重複イベント、誤った指示ID、APIエラーを流します。合格条件を「画面が出る」ではなく、期待するイベント件数、未割当件数、訂正履歴、ERP送信結果で記録します。FATで再現できない設備固有の挙動は、未検証事項としてSATへ引き継ぎます。
SAT(現地受入試験)は実設備・実シフト・実ネットワークで、運用できるかを確認します。班長と作業者が指示を切替え、工程を通し、不良を登録し、交代時に実績を照合します。実績の一致率だけでなく、例外を誰が何分で解決できるか、夜勤に支援があるかを見ます。試験日だけ供給者が手動で裏側を修正して成立させる方法は、日常運用の証拠になりません。試験記録には入力条件、時刻、画面、ログ、合否、残課題、再試験日を残します。
数値目標は工場で決めるべきです。「収集率99%」という表現だけでは母数が不明です。たとえば対象指示の完了イベントのうち、指定時間内に正しい指示・ロットへ帰属した割合、と定義してから目標値を決めます。通信断を含む試験で欠落ゼロを求めるなら、ローカル保存と復旧時間の前提も書きます。設備そのものに信号がない工程を母数に入れるかも合意が必要です。これらは契約上の検収値であり、業界共通の保証値ではありません。

導入順序は一ラインの検証から、異なる設備へ広げる
最初の対象は「最も簡単な設備」だけでも「最も難しい設備」だけでも、全社展開の判断材料として偏ります。代表的な一ラインを選び、PLCから取れる工程と人入力が必要な工程、指示切替と不良処理を含めます。そこでイベント定義、端末の操作、照合、ERP連携を一周させます。次に型式の違う設備へ広げ、タグの再利用率と例外処理の量を測ります。導入工程を増やす前に、マスタ所有者と保守担当が自分たちで変更できるか確認してください。
段階展開では旧帳票をすぐ捨てず、短期間の並行記録で差異の原因を特定します。ただし並行期間を無期限にすると二重入力が常態化します。廃止条件を事前に決め、帳票ごとにいつ入力を止めるか明確にします。教育は操作手順だけでなく「どの数値を見て異常と判断するか」「未割当を誰に回すか」を含めます。現場に日本語・タイ語の管理者がいる場合は、画面ラベルだけでなく、例外理由と手順書の訳語を合わせてください。
本稼働後の運用指標として、未割当イベント数、二重受信件数、遅延到着件数、日次照合の所要時間、手修正件数、端末のオフライン時間を見ます。これらが増えたときに何を調べるかを担当者に渡します。可視化された生産性の改善はその次の段階です。まず、数字を信頼できる状態にすることが導入効果を測る前提になります。設備の状態監視や製造日報の電子化に関心がある場合も、ここで作った実績イベントと帰属ルールを共通基盤として再利用できます。
OTセキュリティと保守性を現場の条件として扱う
新しいゲートウェイを接続する時は、PLCに不要な書込み権限を与えず、読み取り経路と管理経路を分けます。端末の更新、証明書の期限、アカウント廃止、ログ保全、バックアップ復元を誰が担うかを決めます。工場の安全と稼働を優先し、ITネットワーク側の一般的な更新方針を制御機器へ無条件に当てはめないでください。NIST SP 800-82 Rev.3はOT特有の性能・信頼性・安全要求を踏まえたセキュリティ指針を示しています。NISTの原文を設計レビューの参照にできます。
OPC UAの証明書が必要な構成では、初回接続だけでなく、更新・失効・機器交換時の手順まで保守範囲に入れます。通信が暗号化されているという説明と、運用で信頼リストが適切に管理されることは別です。供給者が退場した後でも、工場の担当者が設備追加と復旧を実施できるよう、設定一覧、バックアップ、接続図、権限表、試験記録を納品物にします。ベンダーの遠隔保守を使う場合は、接続時間と承認者、作業ログ、終了後の権限停止を定義します。
見積比較の前に作る「データ契約」
システム間連携を発注する前に、送るデータの契約を一枚にまとめます。項目名だけでなく、値の定義、必須条件、単位、時刻、版数、識別子、欠損時の扱い、訂正方法、保存期間、送信頻度、応答コードを書きます。たとえば「数量」という項目が一つでも、工程投入数、工程完了数、検査合格数、箱詰め数では意味が違います。数量が負になる訂正を許すか、返品や再加工を別イベントにするかも決めます。受信側が解釈を変えると、送信側の設備設定が同じでも月次の数字が変わるためです。
識別子については、工場コード、ラインコード、設備コード、指示ID、工程ID、ロットIDを一覧にして、誰が発行し、いつ廃止し、再利用できるかを定めます。シリアル番号を設備ごとに採番する工場では、設備交換後に同じ番号が現れる可能性があります。イベントIDには発行元を含め、再送しても変えない設計にします。APIの送信時に毎回新しいIDを作ると、同じ生産を別の実績として受け取る危険があります。
受信側の拒否理由も契約に含めます。「指示なし」「ロット未登録」「工程順序違反」「締め済み期間」「単位不一致」を区別し、機械的に再送すべきものと、人の修正が必要なものを分けます。すべての失敗を無限に再送すると、エラーの山が増え、後から何が反映されたか分からなくなります。保留キューの一覧、担当者への通知、再処理ボタン、処理履歴まで含めて一つの業務機能として検収します。データ契約の版を変える時は、旧版の端末が混在する移行期間も試験します。
どこまで自動化するかを決める三つの判定軸
第一の判定軸は信号の確実性です。ワークがセンサーを通った回数と完成品の数が常に一致する工程なら、自動化しやすいでしょう。一方、同じワークが検査機を複数回通る工程では、通過信号をそのまま完了数にできません。試運転や空運転でも信号が出る設備もあります。必ず現物とログを同時に観察し、信号が意味する物理事象を定義します。
第二は人の判断が必要かです。目視検査の良否、手直し理由、材料代替の承認などは、現場の判断をデータとして残す必要があります。入力をゼロにする目標を先に置くと、説明できない自動判定が増えます。判断の回数を減らすより、選択肢を整理し、入力時点を作業の自然な区切りに合わせ、後からまとめて記入しなくて済むようにする方が重要です。
第三は経済性と保守性です。まれにしか使わない旧設備に高価な改造を入れるより、共用端末から開始・完了を記録し、日次照合する方が妥当な場合があります。逆に大量生産ラインで一個ずつ人が数える方式は負担が大きく、入力遅延も増えます。設備別に「全自動」「自動+確認」「人入力」の三段階を定め、現在の問題と将来の増産計画に照らして選びます。方式を混在させても、実績イベントの共通項目を守ればMESとERPの後段処理を統一できます。
本稼働後に数字がずれた時の切り分け手順
実績が合わない時に、まずERPだけを直す運用は避けたいところです。最初に対象の指示、工程、設備、ロット、シフト、時刻帯を固定し、現物・帳票・PLC・ゲートウェイ・MES・ERPの順に数量を並べます。どの境界で差が初めて現れたかが分かれば、センサーの誤検知、指示の誤切替、送信失敗、二重受信、マスタ不整合、承認待ちのどれを調べるべきか絞れます。総量だけ比較すると、あるロットの過大計上と別ロットの過少計上が相殺されます。
次に元イベントを確認します。設備信号は発生していたか、ゲートウェイは保存したか、イベントIDは同じまま再送されたか、MESが受け付けたか、未割当キューに入ったか、ERPが処理を拒否したかを時系列で追います。各段階で時刻の基準が違う場合は、表示上の順序だけで判断せず、発生時刻と受信時刻を分けて見ます。原因が分かったら訂正を行い、元イベント・訂正理由・承認者を残します。
最後に再発防止を選びます。センサー位置の問題なら設備側を直す。画面の選択ミスなら端末の初期値や警告を変える。指示マスタの遅延なら登録の責任と締切を変える。通信断なら保存容量や復旧手順を改善する。どの問題もソフト改修だけで解けるとは限りません。この切り分け手順をSATの時に一度練習しておくと、稼働後に夜勤で差異が起きても、関係者が同じ証拠を見て対処できます。
導入の成否を判定する時は、初日だけの実演ではなく、少なくとも異なる製品への切替とシフト交代を含む期間を選びます。生産量が少ない日の試験では見えない入力待ちや通信遅延が、繁忙時に現れることがあるからです。量産条件で試せない項目は未検証として記録し、本稼働後の確認日と責任者を明確にします。合格・不合格を曖昧にしないため、想定外の事象を誰が承認して次へ進めるかも決めておきます。
また、受入後の変更管理も契約に残します。設備の追加、タグの名称変更、工程の統合、品番マスタの改訂が起きた時に、現場・生産技術・情報システムの誰が影響を確認し、どの試験を再実施するかを決めます。これがないと、最初は合っていた実績が数か月後に静かにずれていきます。
生産実績の自動収集導入でよくある質問
生産実績の自動収集とは、PLCを読むだけで実現しますか?
いいえ。PLCから取得できるのは設備が知る値です。製造指示、ロット、良否、訂正、承認、ERPへの確定値との関係が必要です。カウンターの意味とリセット条件も確認してください。センサーだけで分からない情報は現場端末から取得し、どの値が自動で、どの値が人の判断かを証跡に残します。
古い機械にPLC通信口がない場合、導入できますか?
可能な場合があります。後付けの検知器、既存の外部接点、手入力端末などから選びます。ただし設備の安全回路へ無断で接続せず、改造承認と保守責任を確認します。信号の信頼性が低い場合は、無理な全自動化より、少ない入力項目と照合手順を設計する方が実用的です。
生産実績自動収集の費用は何で変わりますか?
対象設備数だけでなく、機種のばらつき、信号の取り出しやすさ、端末台数、指示・ロットの運用、オフライン要件、MES/ERPのAPI改修、検収範囲で変わります。RFPではライセンス、工事、設備改造、連携、試験、教育、保守を分けて見積もってもらい、同じ受入シナリオで比較します。本記事は一律の価格を提示しません。
オフライン中の数量は、復旧後に必ずERPへ反映すべきですか?
復旧後に送る前に、指示の有効期間、ロット、締め状態を検証します。遅延イベントがすでに確定した期間へ届いた場合は、自動計上するか承認待ちにするかを業務規則で決めます。通信再開と業務確定は別の状態です。同じイベントを二度受けても数量が増えないことを試験してください。
FATとSATでは何を分担しますか?
FATは模擬信号で論理、状態遷移、例外処理を再現します。SATは実設備と作業者、実ネットワーク、シフト交代を含む現地運用を検証します。両方で期待値、証跡、残課題を記録し、FATで試せなかった設備固有条件をSATへ明示的に引き継ぎます。
まとめ
生産実績の自動収集導入は、PLC接続の案件であると同時に、製造指示・ロット・品質・在庫の責任を定める案件です。最初に利用目的と実績イベントを定義し、設備信号と人入力を役割分担し、指示切替とオフラインを含む受入シナリオをRFPへ書きます。FATで論理、SATで現場運用を検証し、MESとERPの確定値まで追えれば、後から改善に使える数字になります。
タイ工場で設備ごとの取得方法や既存MES・ERPとの境界を整理する段階なら、TOMAS TECHへご相談ください。対象ラインの現状と、どの判断に実績を使いたいかが分かれば、最小の検証範囲から一緒に検討できます。