Dashboard ที่อัปเดตเร็วไม่ได้หมายความว่าข้อมูลพร้อมใช้วิเคราะห์ OEE เสมอไป หากสัญญาณเครื่องหยุดถูกตีความผิด หรือจำนวนผลิตถูกนับซ้ำ ค่าในรายงานก็อาจพาทีมไปแก้ปัญหาผิดจุด
การเชื่อม AIoT กับ ระบบ OEE จึงควรเริ่มจากข้อตกลงเรื่องเวลา สถานะ และจำนวนผลิต แล้วค่อยใช้ AI ช่วยจัดกลุ่มหรือสรุปเหตุการณ์ บทความนี้เป็นแนวทางออกแบบข้อมูลสำหรับโครงการนำร่อง ไม่ใช่ผลการทดสอบระบบจริง
ระบุข้อมูลที่ใช้คำนวณก่อนเลือก Dashboard
ทีมผลิตและผู้พัฒนาควรตกลงวิธีนับเวลาที่วางแผนผลิต เวลาที่เดินจริง จำนวนผลิตทั้งหมด จำนวนดี และรอบเวลามาตรฐานของสินค้านั้น ๆ รวมถึงวิธีจัดการการเปลี่ยนสูตรและงาน rework
ตัวอย่างสมมติ: วางแผนผลิต 60 นาที เดินจริง 45 นาที รอบมาตรฐาน 2 วินาทีต่อชิ้น ผลิตรวม 1,200 ชิ้น และได้ของดี 1,176 ชิ้น จะได้ Availability 75%, Performance ประมาณ 88.89%, Quality 98% และ OEE ประมาณ 65.33% ตัวเลขนี้มีไว้แสดงการคำนวณ ไม่ใช่เป้าหมายหรือผลจากโรงงานลูกค้า
กำหนดสถานะเครื่องให้คนและระบบเข้าใจตรงกัน
เริ่มจากสถานะที่อุปกรณ์บอกได้จริง เช่น เดิน หยุด และไม่ทราบสถานะ แล้วค่อยเพิ่มบริบทจากใบสั่งผลิตหรือพนักงาน การไม่มีข้อมูลไม่ควรถูกนับเป็นเวลาที่เครื่องเดินโดยอัตโนมัติ
| เหตุการณ์ | ข้อมูลที่ควรเก็บ | |---|---| | เปลี่ยนสถานะ | รหัสเครื่อง สถานะก่อนและหลัง เวลาแหล่งกำเนิด | | เพิ่มจำนวนผลิต | ตัวนับหรือผลต่าง พร้อมรหัสเหตุการณ์ | | เปลี่ยนสินค้า | รหัสสินค้า สูตร และรอบเวลาที่อนุมัติ | | ระบุเหตุหยุด | ช่วงเวลาที่ครอบคลุม เหตุผล ผู้บันทึก | | แก้ไขข้อมูลย้อนหลัง | ค่าเดิม ค่าใหม่ เหตุผล และผู้อนุมัติ |
สัญญาณจาก PLC อาจบอกเพียงว่าเครื่องหยุด แต่ไม่ได้บอกว่าหยุดเพราะรอวัตถุดิบ เปลี่ยนสินค้า หรือซ่อม การให้พนักงานเติมเหตุผลในช่วงเวลาที่เกี่ยวข้องจึงเป็นข้อมูลอีกชนิดหนึ่งที่ต้องตรวจสอบ
ป้องกันข้อมูลซ้ำ ขาด และมาถึงช้า
ให้แต่ละเหตุการณ์มีรหัสที่ใช้ตรวจซ้ำได้ คงทั้งเวลาที่เกิดและเวลาที่เซิร์ฟเวอร์รับไว้ หากเกตเวย์ส่งคิวเดิมซ้ำหลังเครือข่ายกลับมา ระบบต้องไม่เพิ่มจำนวนผลิตอีกรอบ
กำหนดวิธีจัดการตัวนับรีเซ็ต เครื่องเปลี่ยนกะ ข้อมูลมาถึงผิดลำดับ และเวลาของอุปกรณ์คลาดเคลื่อน ข้อมูลที่ยังไม่ครบควรมีเครื่องหมายคุณภาพหรือสถานะรอปรับปรุงรายงาน
OPC Foundation อธิบายการใช้โมเดลข้อมูลอุตสาหกรรมร่วมกับแนวทางเชื่อม Edge และ Cloud ใน Cloud Initiative ส่วนการใช้ MQTT หรือ OPC UA ในโครงการต้องกำหนดหัวข้อข้อมูล หน่วย สิทธิ์ และเงื่อนไขการรับส่งให้ตรงกับอุปกรณ์จริง
ให้ AI ช่วยอธิบายโดยย้อนกลับไปดูเหตุการณ์ได้
เมื่อข้อมูลพร้อมแล้ว อาจเริ่มให้ AI สรุปกลุ่มเหตุหยุดที่มีเวลารวมสูง หรือหาช่วงที่เหตุการณ์เกิดร่วมกัน คำสรุปควรมีรายการเหตุการณ์ ช่วงเวลา และเงื่อนไขกรองให้เปิดตรวจได้
การเกิดพร้อมกันยังไม่ยืนยันเหตุและผล ถ้าเครื่องหยุดใกล้กับการเปลี่ยนสูตร ระบบควรเสนอเป็นข้อสังเกตให้ตรวจ ไม่สรุปทันทีว่าการเปลี่ยนสูตรเป็นต้นเหตุ และไม่แก้เหตุหยุดที่ผู้ใช้บันทึกไว้โดยไม่มีร่องรอย
ทดลองด้วย Digital Twin ก่อนต่อข้อมูลจริง
ใช้ OEE Digital Twin 3D ทดลองว่าเครื่องหยุด เดินช้า และเกิดของเสีย ส่งผลต่อตัวชี้วัดอย่างไร Demo นี้เป็นข้อมูลจำลอง ไม่ใช่ข้อมูลจากเซนเซอร์หรือผลรับรองระบบหน้างาน
จากนั้นทำการทดสอบกับเครื่องนำร่อง โดยเทียบตัวนับกับบันทึกหน้างาน ตรวจเหตุการณ์ข้ามกะ และจำลองเครือข่ายขัดข้องก่อนขยาย หากต้องการเชื่อมใบสั่งผลิตต่อ สามารถวางร่วมกับ MES และสำรวจตัวอย่างอื่นที่ Demo Center
ติดต่อเพื่อทบทวนสัญญาณเครื่องและนิยามข้อมูล OEE ก่อนเริ่มเชื่อมต่อจริง จะช่วยให้ขอบเขตงานและเกณฑ์รับมอบชัดเจนขึ้น
