Case Study: Event Streaming Backbone — เมื่อข้อมูลโรงงานอาหาร 3 ไซต์ ไหลเร็วกว่าสินค้าขึ้นหน้าร้าน

โจทย์: โรงงานอาหาร 3 ไซต์ ที่ข้อมูลเดินทางช้ากว่าสินค้า

ลองนึกภาพโรงงานอาหารกลางในภาคตะวันออก ผลิตของว่างบรรจุถุงส่งให้ร้านค้าปลีกทั่วประเทศ มี 3 ไซต์ผลิต แต่ละไซต์มีสายการผลิต 4–6 ไลน์ ปัญหาที่ฝ่ายผู้อำนวยการเล่าให้ฟังตอนเริ่มโครงการคือ — “ตอนสินค้าถึงมือหน้าร้าน ข้อมูลการผลิตยังไปไม่ถึงโต๊ะผม” รายงาน OEE รายไลน์ต้องรอรวบรวมถึงเช้าวันถัดไป ส่วนข้อมูล lot ที่ถูกเรียกคืน (recall) ต้องใช้เวลานานหลายชั่วโมงในการไล่หาว่าวัตถุดิบก้อนไหนเข้าสายการผลิตไหน

เมื่อไล่ปัญหาลึกลงไป เจอรากที่แท้จริง 3 ข้อ:

• Point-to-Point เต็มระบบ — MES ดึงข้อมูลจาก SCADA ทุกไลน์ด้วย interface เฉพาะ 6 ชุด, ระบบคลังดึงจาก MES อีกชุด, ฝ่ายพลังงานต่อมิเตอร์แบบแยกเดียว รวมแล้ว interface ที่ต้องดูแลเกือบ 20 จุด แก้ทีไรกระทบลูกโซ่ทุกครั้ง
• รูปแบบข้อมูลไม่เหมือนกัน — แต่ละไซต์ตั้งชื่อ tag ตามใจ integrator ที่ติดตั้งปีไหนปีนั้น คำว่า “อุณหภูมิห้องเย็น” มีถึง 4 ชื่อต่างกันข้ามไซต์
• ข้อมูลถึงสาย แต่ไม่มีใครกล้าใช้ — เพราะไม่มีใครรับประกันว่าค่าที่เห็นบน dashboard เป็นค่าปัจจุบันหรือค่าค้างจากอุปกรณ์ที่หลุดไปแล้ว

ทางออก: วาง Event Streaming Backbone พร้อม Event Carried State Transfer

ทีม integrator เสนอแนวทางที่ไม่ใช่การซื้อ “อีกระบบนึงมาต่อพ่วง” แต่เป็นการวาง แกนกลางกระจายเหตุการณ์ (Event Streaming Backbone) ให้ทั้ง 3 ไซต์ โดยออกแบบตามแนวคิด Event Carried State Transfer — ทุกเหตุการณ์สำคัญบนสายการผลิต (เปลี่ยนรุ่นผลิต, หยุดไลน์, ผลิตครบ lot, อ่านค่า QC ผ่าน/ไม่ผ่าน) จะถูกแปลงเป็น “เหตุการณ์” ที่พกสถานะล่าสุดของตัวเองมาด้วยเสมอ

เหตุการณ์ (Event) คือบันทึกที่เปลี่ยนแปลงไม่ได้ (immutable record) ว่า “เกิดอะไรขึ้น” ประกอบด้วย key ที่ระบุตัวตน, value ที่เก็บข้อมูลจริง, และ timestamp บอกเวลาที่เกิดเหตุการณ์ — นิยามตามเอกสารของ Apache Kafka โครงการ open source ที่เป็นมาตรฐาน de facto ของวงการ event streaming

สถาปัตยกรรมที่วางจริงมี 4 ชั้น:

1. ชั้น Edge — IIoT Gateway ประจำไลน์อ่านค่าจาก PLC และเซ็นเซอร์ แล้วแปลงเป็นเหตุการณ์มาตรฐานชุดเดียวข้ามไซต์ (ข้อตกลงตั้งชื่อและโครงสร้าง payload ทำร่วมกัน 3 ไซต์ในคราวเดียว)
2. ชั้น Broker/Log กระจาย — เหตุการณ์ถูกเขียนลง distributed log แบบ topic คั่นตามพื้นที่ผลิต จัดเก็บตามลำดับที่ได้รับ และ ไม่ถูกลบหลังมีคนอ่าน — ผู้บริโภคหลายระบบอ่านข้อมูลชุดเดียวกันได้อย่างอิสระ ใครพังก็เริ่มอ่านใหม่จากตำแหน่ง (offset) ล่าสุดของตัวเอง
3. ชั้นประมวลผล — กฎการรวม/กรอง เช่น นับจำนวนหยุดไลน์ต่อชั่วโมง หรือจับคู่ข้อมูล QC กับ lot ทำแบบ stream processing ขณะข้อมูลไหลผ่าน
4. ชั้นปลายทาง — Data warehouse, ระบบวิเคราะห์ และ application ต่างๆ ดึงข้อมูลจาก backbone โดยไม่ต้องต่อตรงเข้าไลน์ผลิตอีก

จุดชี้ขาด: Dead Letter Queue + Consumer Offset

สิ่งที่ทำให้ทีมดูแล “กล้าใช้ข้อมูล” อีกครั้งไม่ใช่ตัว broker เอง แต่เป็นกลไก 2 อย่างที่มาพร้อมสถาปัตยกรรมนี้:

• Dead Letter Queue (DLQ) — เหตุการณ์ที่รูปแบบผิดพลาดหรือประมวลผลไม่ผ่านจะถูกแยกไปคิวพิเศษ พร้อมสาเหตุ แทนที่จะหายไปเงียบๆ หรือค้างบั่นทอนทั้งสาย ทีม data ตรวจ DLQ เป็นกิจวัตรเช้าตรู่ จึงรู้ปัญหาข้อมูลก่อนที่ผู้ใช้รายงานเสมอ
• Consumer Offset — ทุกระบบปลายทางจำตำแหน่งที่ตัวเองอ่านถึง ถ้าระบบ OEE ล่มตอนกลางคัน เมื่อกลับมาก็ไล่อ่านต่อจากจุดเดิม ข้อมูลไม่หาย ไม่ซ้ำ ไม่ต้อง sync ด้วยมือ

ผลลัพธ์: ข้อมูลแซงหน้าสินค้า

ที่น่าสนใจคือ ผลลัพธ์ที่โรงงานไม่ได้ตั้งใจไว้: เมื่อข้อมูลไหลถึงมือทั้งองค์กรแบบเดียวกัน ทีมพัฒนาผลิตภัณฑ์เริ่มขอเชื่อมข้อมูลอัตราของเสียกับข้อมูลอุณหภูมิห้องผลิตเพื่อหาความสัมพันธ์ และทีมซ่อมบำรุงขอดูข้อมูล stoppage ย้อนหลังเพื่อวางแผนงาน — งานที่ก่อนหน้านี้ต้องตั้งโครงการเพื่อขอข้อมูลเป็นครั้งคราว กลายเป็นเรื่องเปิดดูได้เอง

ประสบการณ์แบบนี้สอดคล้องกับงานที่ทีม Honey Corporation ทำในโรงงานไทย เช่น ระบบ IoT monitoring ตู้แช่ Freezer ที่ต้องส่งข้อมูลอุณหภูมิแบบเรียลไทม์พร้อมบอกสถานะอุปกรณ์ว่าออนไลน์อยู่หรือไม่ — หัวใจเดียวกันคือ ข้อมูลไม่แค่ต้องไหล แต่ต้องไหลแบบที่คนกล้าใช้ตัดสินใจ เราจึงให้ความสำคัญกับการออกแบบโครงสร้างข้อมูลและกลไกความน่าเชื่อถือตั้งแต่ขั้นออกแบบ ไม่ใช่มาเติมทีหลัง

Key Takeaways — บทเรียนจากกรณีศึกษา

• ตกลงโครงสร้างข้อมูลร่วมกันก่อนแตะฮาร์ดแวร์ — งานหนักที่สุดของโครงการนี้ไม่ใช่การติดตั้ง แต่คือการนั่งตกลงชื่อ field และความหมายร่วมกันข้าม 3 ไซต์
• อย่ารื้อของเดิม ให้ต่อขนาน — ระบบเดิมยังทำงานต่อ ส่วน gateway ค่อยๆ เพิ่มข้อมูลขึ้น backbone ทีละไลน์
• วาง DLQ และ monitoring ตั้งแต่วันแรก — ความเชื่อมั่นของผู้ใช้ข้อมูลสร้างจากการเห็นปัญหาถูกจับได้ก่อนระเบิด ไม่ใช่จากคำสัญญา
• เริ่มวัดผลจาก use case เจ็บที่สุด — เลือกงานที่เจ็บปวดที่สุดของธุรกิจ (อย่างเช่น recall tracing) มาทำก่อน เพื่อให้คุณค่าเห็นชัดเร็ว
• ออกแบบให้ผู้บริโภคข้อมูลเพิ่มได้เรื่อยๆ — ประโยชน์จริงของ backbone เกิดตอนที่ทีมใหม่ๆ ขอเข้ามาใช้ข้อมูลเองโดยไม่ต้องตั้งโครงการ