ระบบเก็บข้อมูลผลการผลิต｜ออกแบบ RFP และการยืนยันสำหรับโรงงานไทย 2026

ระบบเก็บข้อมูลผลการผลิต สำหรับโรงงานไทยไม่ได้เสร็จสมบูรณ์เพียงเพราะอ่านค่าจาก PLC แล้วแสดงตัวเลขบนหน้าจอได้ ระบบต้องไม่ลงยอดซ้ำเมื่อมีการส่งข้อมูลใหม่ ต้องแยกการกรอกย้อนหลังจากเหตุการณ์จริง ต้องไม่ส่งผลตรวจที่ยังไม่อนุมัติไป ERP และต้องติดตามการแก้ไขได้ทุกครั้ง บทความนี้แปลง “ความถูกต้องของบันทึก” และ “ผู้รับผิดชอบการยืนยัน” ให้เป็นข้อกำหนด RFP, PoC, FAT และ SAT ที่ตรวจรับได้

ระบบเก็บข้อมูลผลการผลิตต้องพิสูจน์มากกว่าการมองเห็น

การนำสัญญาณเครื่องจักรขึ้น dashboard ทำได้ค่อนข้างเร็ว แต่ตัวเลขที่เห็นยังไม่ใช่ผลการผลิตที่เชื่อถือได้เสมอไป บิต completion ที่เปลี่ยนสถานะอาจหมายถึงชิ้นดีหนึ่งชิ้น การเดินเครื่องเปล่า งานทดลอง แม่พิมพ์หลาย cavity หรือชิ้นงานที่ยังรอตรวจ หากเครือข่ายกลับมาแล้วส่ง message เดิมซ้ำ การนับตามจำนวนที่รับจะทำให้ผลผลิตสูงเกินจริง

ข้อมูลที่จะใช้วางแผน สต็อก ต้นทุน หรือส่งมอบ ต้องตอบได้ว่าเกิดอะไรขึ้น ที่ site, line, เครื่องจักร, operation, order, item และ lot ใด เกิดเมื่อไร ระบบรับเมื่อไร ใครยืนยันเมื่อไร มาจาก raw record และ rule version ใด ส่งซ้ำแล้วนับครั้งเดียวหรือไม่ อยู่ในสถานะ provisional, confirmed, posted หรือ cancelled และใครแก้เพราะเหตุใด

การมองเห็นความคืบหน้ากระบวนการต้องสร้างบนฐานนี้ ถ้าฐานไม่แน่น หน้างานจะเก็บกระดาษหรือ Excel คู่ขนานและใช้ตัวเลขระบบเป็นเพียงข้อมูลอ้างอิง ดังนั้นให้กำหนด event identity, state transition, deduplication และสิทธิ์แก้ไขก่อนเลือกรูปแบบกราฟ

ออกแบบการเก็บผลการผลิตเป็น 5 สถานะ

อย่าทำให้ข้อมูลทุกชุดที่เข้ามากลายเป็น “ลงบัญชีแล้ว” ทันที ให้แยกเป็น:

1. Raw — ค่า PLC, sensor, barcode scan หรือ operator input ที่รับมาโดยยังไม่ตีความ
2. Event — เหตุการณ์ทางธุรกิจ เช่น เริ่ม operation, ผลิตเสร็จหนึ่งครั้ง, ตรวจ NG
3. Provisional — ผูก order, item, lot, operator และ unit แล้ว แต่ยังไม่ยืนยัน
4. Confirmed — ผู้มีอำนาจหรือกฎที่อนุมัติยืนยันให้เป็นผลการผลิตทางการ
5. Posted — ERP/สต็อก/ต้นทุนตอบกลับและกระทบยอดแล้ว

ควรเก็บ raw evidence เพื่อให้คำนวณใหม่ได้เมื่อแก้ mapping logic แต่ต้องกำหนด retention, capacity, access และ privacy การเก็บทุกอย่างตลอดไปไม่ใช่ข้อกำหนดที่ดี ข้อมูล confirmed ไม่ควรถูก overwrite ให้เพิ่ม cancellation event และ correction event เพื่อรักษาค่าเดิม เหตุผล และผู้แก้ หากส่ง ERP แล้ว ต้องยกเลิกหรือ repost ฝั่ง ERP ด้วย ไม่ใช่แก้เฉพาะหน้าจอ MES

แยก raw signal ออกจาก business event

บิต register หรือ counter ของ PLC แสดงสถานะควบคุม ส่วนผลการผลิตคือความหมายทางธุรกิจ ระหว่างสองส่วนต้องมี mapping rule ที่ตอบเรื่อง pulse, debounce, PLC restart, multi-cavity, trial, dry cycle, quality state และ counter reset/rollover

แนบ event-definition table ใน RFP โดยระบุ source, trigger, debounce, quantity rule, work-order mapping, quality state, event-ID rule, error handling และ owner สำหรับทุก event การตอบว่า “รองรับ OPC UA” ยังไม่เพียงพอ

OPC UA PubSub รองรับการกระจายข้อมูลแบบรอบและแบบ event และแยก publisher ออกจาก subscriber ได้ แต่การระบุว่า DataSetMessage ใดเป็นผลของ order ใดคือข้อตกลงใน application จึงต้องประเมิน connectivity แยกจากความถูกต้องของผลการผลิต

แบ่งหน้าที่ระหว่าง PLC ผู้ปฏิบัติงาน การตรวจ และ barcode

PLC เก็บจุดเกิดที่เป็นข้อเท็จจริง

PLC เหมาะกับ cycle start/end, machine state, counter และ alarm แต่อาจไม่รู้ order ที่ถูกต้อง เหตุผล defect หรือผล quality สุดท้าย ไม่ควรยัด master ธุรกิจทั้งหมดไว้ใน control logic ให้ PLC สร้าง source event แล้ว edge/MES ผูกกับ order assignment ที่มีช่วงเวลาบังคับใช้ ถ้าผูกไม่ได้ให้ส่งเข้า exception queue โดยไม่ทิ้ง event เมื่อแก้ภายหลังต้องรักษา event ID และเวลาเดิม

ผู้ปฏิบัติงานเติมความหมายและข้อยกเว้น

setup complete, downtime reason, rework reason และ disposal reason มักต้องใช้คน เลือก reason code ที่ควบคุมได้และเปลี่ยนตัวเลือกตาม context แทน free text ใช้ code เป็น master key แล้วแสดงชื่อภาษาไทย อังกฤษ และญี่ปุ่น

แยกเวลาที่ผู้ปฏิบัติงานเลือกจากเวลาที่ส่ง ถ้า terminal offline ต้องเก็บ queue แบบ durable และแสดง local saved, sent, received, confirmed ให้ต่างกัน บัญชีร่วมทำให้ติดตามผู้แก้ไม่ได้ จึงควรใช้ named identity หรือวิธีประจำกะที่อนุมัติและแยกหน้าที่ชัดเจน

ผลตรวจไม่ควร overwrite จำนวนผลิต

แบบหนึ่งลง completion เป็น provisional แล้วแบ่งเป็น good, reject, hold, rework หลังตรวจ อีกแบบใช้ inspection pass เป็น good-output event ทั้งสองใช้ได้ตามกระบวนการ แต่ไม่ควร overwrite ทุกจำนวนไว้ใน counter เดียว

กำหนดสมการความสอดคล้องของ completed, inspected, accepted, rejected, held และ reworked รวมถึง sampling, retest version และ quality approval หากสต็อกหรือ quality lot ถูก posted แล้ว correction workflow ต้องไปถึงระบบปลายทาง

Barcode ระบุตัวตน แล้วจึงตรวจความถูกต้อง

barcode ใช้ระบุ order, item, lot, serial, container หรือ operator ได้ แต่การอ่านสำเร็จไม่ได้แปลว่า code นั้นใช้ได้ ต้องตรวจ routing sequence, expiry, prior use, duplication, item match และ machine eligibility ให้ scan แต่ละครั้งมี event ID ของตนเอง การ debounce ตามเวลาอย่างเดียวแยก double scan ผิดพลาดจากการทำงานจริงสองครั้งไม่ได้

กำหนดขอบเขต MES–ERP ด้วยเจ้าของการยืนยัน

ISA-95 ช่วยจัดศัพท์ระหว่าง physical process, sensing/control, manufacturing operations management และ enterprise function แต่ไม่ได้บังคับ topology เดียวทุกโรงงาน ให้กำหนด system of record และสิทธิ์ยืนยันของข้อมูลแต่ละชนิด

SAP Production Order Confirmation API เป็นตัวอย่างที่มีเวลาเริ่ม/จบ yield, scrap, rework, variance reason และ final confirmation type แม้ไม่ใช่มาตรฐาน ERP ทั้งหมด แต่แสดงว่าผลการผลิตไม่ใช่แค่ quantity

กำหนดว่า ERP posting เริ่มเมื่อ confirmed, supervisor approved หรือ shift closed หาก ERP timeout อย่าตั้ง Posted เพียงเพราะส่ง request แล้ว ให้เก็บ posting request ID, target response ID และ result code และเปลี่ยนสถานะหลัง reconciliation เท่านั้น

อ่าน 4 แกนสำหรับเปรียบเทียบ MES เพื่อประเมินความเหมาะสมของผลิตภัณฑ์ และใช้ คู่มือ RFP จ้างพัฒนาระบบโรงงานไทย เมื่อมี custom integration หรือ software

แยก event_time, received_at และ confirmed_at

timestamp เดียวอธิบาย network outage, late entry และ approval delay ไม่ได้ ควรมีอย่างน้อย:

• event_time — เวลาเหตุการณ์จริงที่หน้างาน
• received_at — เวลา edge, broker หรือ MES รับและบันทึก
• confirmed_at — เวลาที่ยืนยันเป็นผลการผลิตทางการ

GS1 EPCIS ก็แยก eventTime ของโลกจริงจาก recordTime ของ repository แม้ไม่ใช้ EPCIS หลักการนี้ยังมีประโยชน์ ให้เก็บ timezone offset, clock source และ clock status สำหรับการทำงานข้ามไทย ญี่ปุ่น และเวียดนาม

หากนาฬิกาอุปกรณ์คลาด event_time อาจอยู่หลัง received_at กำหนด clock skew ที่ยอมได้ วิธี sync, loss-of-sync flag และ correction rule หากแก้เวลาให้เก็บ original และ corrected_event_time พร้อมเหตุผล Dashboard ต้องระบุว่าใช้เวลาใด: event time สำหรับเหตุการณ์หน้างาน received time สำหรับ pipeline latency และ confirmed time สำหรับการปิดยอด

จัดการการส่งซ้ำ ข้อมูลซ้ำ และลำดับสลับด้วย business ID

MQTT 5.0 QoS 1 เป็น at-least-once จึงมี duplicate ได้ และ DUP flag ไม่ใช่ตัวตนของ application message QoS 2 เพิ่มความมั่นใจด้าน transport แต่ไม่ป้องกัน DB transaction หรือ ERP posting ซ้ำจาก application retry โดยอัตโนมัติ

กำหนด source_event_id ที่ไม่ใช้ซ้ำระยะยาว เช่น site-line-PLC boot ID-sequence หรือ UUID และบังคับ unique key ID เดิม payload เดิมคือ duplicate ที่บันทึกไว้แต่ไม่นับเพิ่ม ID เดิม payload ต่างกันต้องเป็น critical exception ไม่ใช่ overwrite

ทำ idempotency ทุก boundary: device→edge ด้วย event ID, edge→MES ด้วย event ID และ attempt, MES state ด้วย expected version, MES→ERP ด้วย posting request ID คงที่ และเก็บ ERP document ID เพื่อกระทบยอด

event อาจมาสลับลำดับ เช่น completion มาก่อน start หรือ inspection มาก่อน production completion ให้กำหนด reorder window, prerequisite hold, timeout และ exception queue ลำดับที่ insert DB ไม่ใช่ลำดับการผลิต

ออกแบบ offline recovery เป็นขั้นตอนปฏิบัติการ

โรงงานไทยอาจขาด factory LAN, Wi-Fi, site VPN, cloud, ไฟฟ้า หรือ edge runtime คำว่า “ทำงาน offline ได้” ต้องระบุว่าข้อมูลเก็บที่ไหน นานเท่าไร ลำดับความสำคัญใด และเกิดอะไรเมื่อ storage เต็ม

AWS IoT Greengrass Stream Manager เป็นตัวอย่างทางการที่รองรับ intermittent connectivity, persistence, retention และ export priority ไม่ว่าจะใช้ผลิตภัณฑ์ใดควรมี:

• durable queue ที่รอดจาก edge restart
• append-only journal พร้อม sequence, checksum, source event ID
• priority แยก production event กับ diagnostic data
• monitoring buffer usage, oldest unsent และ dead-letter
• backlog drain ที่ไม่ทำให้ current event ติดค้าง
• safe state เมื่อ disk เต็ม ข้อมูลเสีย clock หาย certificate หมดอายุ
• encryption, key, access และ maintenance control สำหรับ local data

ระหว่าง offline หน้าจอต้องแยก local saved, received และ confirmed หลัง recovery ต้องตรวจ gap, duplicate และจำนวน ERP posting ไม่ใช่เพียง “ส่ง message ครบ”

ใส่ event data contract ใน RFP

RFP ควรมี sample event schema ไม่ใช่เพียงรายการหน้าจอและจำนวนเครื่อง

กำหนด compatibility เมื่อเพิ่ม field เปลี่ยนเป็น mandatory หรือ rollout หลาย version แยก PLC tag mapping จาก canonical event schema เพื่อลดผลกระทบจากการแก้ control

ข้อกำหนด security ต้องระบุ device identity, certificate rotation, least privilege, port/route, remote maintenance, log access, restore test, vulnerability response และการถอนสิทธิ์ ไม่ใช่เขียนเพียง “เข้ารหัส”

ใช้ PoC 30/60/90 วันพิสูจน์ความถูกต้อง

กรอบ 30/60/90 วันเป็นข้อเสนอสำหรับการตัดสินใจ ไม่ใช่มาตรฐานบังคับ

วันที่ 30: ตรึงนิยาม

เลือกหนึ่ง operation แล้วตกลง event definition, ID, clock, state, exception และ owner เก็บตัวอย่าง normal, setup, trial, rework, hold, PLC restart และ work-order change อนุมัติ manual truth set ก่อน demo

วันที่ 60: สร้างหลักฐานจาก failure

ทดสอบ network loss, edge restart, duplicate, out-of-order, ERP timeout, clock skew และ master mismatch ตัวอย่าง 10,000 event, outage 2 ชั่วโมง, retransmission 3 ครั้ง และ skew ±5 นาทีเป็นเพียงค่าทดสอบ ต้องแทนด้วย peak, buffer และ SLA ของโรงงาน

วัด collection completeness, duplicate posting, unreconciled record, confirmation lead time, exception effort, recovery time และ audit gap ดู maximum และ failed case ไม่ใช่ average อย่างเดียว

วันที่ 90: ตรวจรับการปฏิบัติการ

operator ต้องจัดการ exception ภาษาไทย supervisor ต้องยืนยัน IT/OT ต้องไล่จาก alert ถึงสาเหตุ และ ERP user ต้อง reverse/repost รับ operating procedure, access matrix, backup/restore evidence, certificate renewal, support escalation และ known limitation แล้วตัดสิน scale, revise หรือ stop

FAT/SAT ต้องครอบคลุม normal, failure และ recovery

FAT พิสูจน์ schema, deduplication, state, authorization, audit และ interface ในสภาพแวดล้อมผู้ขาย SAT ทำซ้ำด้วย PLC, network, shift, operator และ ERP/MES จริง

ทดสอบ normal event; counter reset และขอบเขตวัน/กะ/lot; LAN, broker, DB, edge, ERP failure; lost ack และ conflicting duplicate; clock drift/timezone; unauthorized confirmation; backlog drain/dead-letter replay; peak load และ disk full

test case แต่ละรายการต้องมี precondition, input, expected event/state, evidence, actual, tester, date และ defect ID ภาพหน้าจอ “pass” อย่างเดียวไม่พอ ต้อง trace event ID เดียวกันจาก raw ผ่าน MES ถึง ERP document

เปรียบเทียบ TCO โดยรวม exception และการเปลี่ยนแปลง

ใช้สมการเดียวกัน:

TCO รายเดือน = license + edge/communication + cloud/database + support + แรงงาน exception + ค่าเปลี่ยนแปลงเฉลี่ย + training/audit

ไม่ควรสร้างราคาตลาดหรือเปอร์เซ็นต์ประโยชน์โดยไม่มีแหล่ง ให้ผู้ขายตีราคาบน assumption เดียวกัน เช่น เพิ่มเครื่องหนึ่งตัว tag สิบจุด event type ใหม่ เปลี่ยน ERP field night support ภาษาไทย spare edge, certificate rotation, patch และ restore test

อัตราเก็บอัตโนมัติสูงแต่มี order ไม่ตรงหรือ clock error จำนวนมากอาจเพิ่มงาน ให้ติดตามจำนวนและอายุ exception, manual correction ratio, recurrence และ root cause ไม่ใช่ automation percentage อย่างเดียว

ข้อผิดพลาดที่พบบ่อยและวิธีแก้

• ใช้ PLC counter เป็น good output: แยก raw completion จาก quality-confirmed quantity
• เก็บ arrival time อย่างเดียว: เก็บ event, received, confirmed
• คิดว่า MQTT QoS แก้ยอดซ้ำ: เพิ่ม event identity และ idempotency
• ทดสอบ outage แค่ ping: ทดสอบ buffer, replay, order, gap และ ERP reconciliation
• overwrite หลัง confirmed: ใช้ cancellation/correction event
• ให้ MES และ ERP เป็น master พร้อมกัน: กำหนด owner ราย field และ state
• จบ PoC ที่ demo เครื่องเดียว: inject failure และทดสอบงานหลายภาษา
• ไม่รวม exception labor ใน TCO: รวม support, renewal, patch และ recovery

FAQ: การเก็บผลการผลิตและการมองเห็นความคืบหน้า

ระบบเก็บข้อมูลผลการผลิตคืออะไร?

คือระบบที่แปลงบันทึกจาก PLC, operator, inspection และ barcode ให้เป็น actual ที่ผูก order/operation แล้วควบคุม provisional, confirmation, ERP posting และ correction ต่างจาก data logger เพราะมี event identity, state, authorization และ audit

เก็บผลการผลิตจาก PLC อย่างเดียวได้หรือไม่?

PLC เหมาะกับ cycle และ status แต่ reason, rework, hold และ order exception ต้องใช้ operator หรือ context ชั้นบน จึงต้องรวมตาม confirmation rule ที่ชัดเจน

ทำไมต้องแยกเวลา event กับเวลายืนยัน?

เพราะ network loss, late entry และ approval ทำให้เวลาไม่ตรงกัน ถ้าไม่แยกจะอธิบาย progress, shift close และ audit ไม่ได้

Dashboard ความคืบหน้าต้องทำ deduplication หรือไม่?

ต้องทำ การส่งซ้ำอาจทำให้ progress เกิน 100% และคาดการณ์เสร็จผิด

MQTT QoS 2 รับประกัน ERP posting ครั้งเดียวหรือไม่?

ไม่ QoS จัดการ transport ส่วน DB commit, service retry และ ERP posting ยังต้องใช้ application event ID และ idempotent processing

PoC, FAT และ SAT ต่างกันอย่างไร?

PoC พิสูจน์นิยามและวิธีในขอบเขตเล็ก FAT พิสูจน์ function/failure ที่ผู้ขาย SAT ทำซ้ำในโรงงานจริงกับผู้ใช้จริง

มี MES อยู่แล้ว ยังควรทบทวนการเก็บผลการผลิตหรือไม่?

ควรทบทวน เพราะอาจเสริม event contract ที่ edge, ID, timestamp, การจัดการ exception และการกระทบยอดกับ ERP ได้โดยไม่ต้องเปลี่ยนหน้าจอ MES เดิม เริ่มจากจัดประเภทข้อมูลตกหล่น ข้อมูลซ้ำ การกรอกย้อนหลัง และการแก้ไขจาก log ปัจจุบัน แล้วปรับเฉพาะส่วนที่จำเป็น

สรุป: ผลการผลิตที่ถูกต้องต้องอธิบายเส้นทางได้

เป้าหมายไม่ใช่เก็บทุกอย่างอัตโนมัติ แต่ต้องเชื่อม raw signal, business event, provisional, confirmation และ ERP posting ด้วย ID ที่คงทน แล้วอธิบายตัวเลขได้หลัง outage, retransmission หรือ correction ใส่ owner, สามเวลา, audit และ recovery reconciliation ใน RFP และ acceptance test

TOMAS TECH ช่วยโรงงานไทยกำหนด event contract ของหนึ่ง operation ขอบเขต PLC/operator/inspection, RFP, PoC 30/60/90 วัน และหลักฐาน FAT/SAT ได้ แม้อยู่ช่วงก่อนเลือกผลิตภัณฑ์ก็ปรึกษาผ่าน หน้าติดต่อ ได้

เอกสารอ้างอิง

• ISA-95
• OPC UA Part 14: PubSub
• MQTT Version 5.0
• GS1 EPCIS 2.0.1
• SAP Production Order Confirmation
• AWS IoT Greengrass Stream Manager