Unified Namespace (UNS): สถาปัตยกรรมข้อมูลกลางยุคใหม่ ที่จบปัญหา Point-to-Point ในโรงงาน IIoT

ทำไมโรงงานยุค IIoT จึงเจอปัญหา “สปาเกตตี้อินทิเกรชัน” กันทุกแห่ง

ถ้าคุณเคยเปิด Excel ที่เก็บรายการ interface ระหว่างระบบในโรงงาน แล้วพบว่ามีเส้นเชื่อมระหว่าง SCADA, MES, ERP, ระบบเก็บพลังงาน และ Dashboard แทบทุกคู่เป็นร้อยเส้น คุณกำลังเจอปัญหาที่วงการอุตสาหกรรมเรียกขึ้นชื่อว่า Point-to-Point Integration Hell ยิ่งจำนวนระบบ (N) เพิ่มขึ้น จำนวนการเชื่อมต่อที่ต้องดูแลจะโตตามสูตร N×(N−1)/2 — มีระบบ 10 ตัวก็คือ 45 การเชื่อมต่อ ทุกจุดต้องเขียนโค้ด mapping แยก ทดสอบแยก และพังคนละจุดกันเงียบๆ

ปัญหานี้เป็นผลพลอยได้ของสถาปัตยกรรมแบบชั้นตามแนวคิด ISA-95 / Purdue Model ที่ใช้กันมาหลายสิบปี แบบจำลองนี้ดีมากในเชิง ความปลอดภัยและการแบ่งลำดับชั้นความรับผิดชอบ แต่เมื่อมาถึงยุคที่ธุรกิจต้องการข้อมูลแบบเรียลไทม์ข้ามระบบ มันกลับกลายเป็นกำแพงที่ทำให้ทุก integration ต้องผ่าน “บันได” ทีละขั้น ช้าและเปราะบาง

“Unified Namespace คือ single source of truth แบบเรียลไทม์ จัดเรียงตามโครงสร้างธุรกิจ และออกแบบให้เปิดกว้าง ไม่ผูกติดกับผลิตภัณฑ์ใด” — นิยามของ Walker Reynolds ผู้บุกเบิกแนวคิด UNS

Unified Namespace (UNS) เสนอทางออกที่ตรงจุด: เปลี่ยนโครงสร้างการเชื่อมต่อจาก point-to-point ที่ต่อกันไปมาเป็น Hub-and-Spoke โดยมี MQTT Broker เป็นศูนย์กลางเดียวที่ทุกระบบมา publish และ subscribe ข้อมูล แทนที่จะต้องเขียน integration เฉพาะทุกคู่ระบบ

หัวใจของ UNS: MQTT + โครงสร้าง Topic ตาม ISA-95

UNS ไม่ใช่ซอฟต์แวร์ที่ซื้อมาติดตั้งแล้วจบ แต่เป็น สถาปัตยกรรมการจัดระเบียบข้อมูลที่ประกอบด้วย 3 ส่วนหลัก: MQTT Broker เป็นแกนกลางการส่งข้อมูลแบบ publish/subscribe, โครงสร้าง topic ที่จัดเรียงตามลำดับชั้นธุรกิจ และ payload ที่มีโครงสร้างและความหมายชัดเจน (เช่น JSON ที่ผ่านการ data modeling มาแล้ว)

โครงสร้าง topic มาตรฐานที่นิยมใช้คือการไล่ลำดับชั้นจากบนลงล่างตามโมเดล ISA-95:

enterprise/<site>/<area>/<line>/<cell>/<device>/<tag>

ตัวอย่าง:
mycompany/bangkok/plant1/line-a/cell-3/conveyor/motor_temp
mycompany/bangkok/plant1/line-a/cell-3/conveyor/speed_setpoint

ข้อดีของการจัด topic แบบนี้คือ ข้อมูลไม่ได้เป็นแค่ “ตัวเลขดิบ” แต่มีบริบทเชิงธุรกิจฝังอยู่ในชื่อ ทีม OEE อยากดูข้อมูลทั้งไลน์ A ก็ subscribe ที่ mycompany/bangkok/plant1/line-a/# ทันที ส่วนทีมพลังงานอยากเก็บเฉพาะมิเตอร์ไฟฟ้าก็ subscribe เฉพาะ branch ที่ต้องการ — ทั้งหมดนี้โดยไม่ต้องแก้โค้ดฝั่งผู้ผลิตข้อมูลเลย

Sparkplug: ชั้นความหมายที่ทำให้ MQTT “พูดภาษาโรงงาน” ได้ครบ

MQTT เปล่าๆ ยังตอบไม่ครบ 2 คำถามสำคัญ: ข้อมูลนี้มีหน่วย/ชนิดอะไร และอุปกรณ์ที่ส่งมายัง “อยู่” หรือไม่ สเปกชันเปิด Sparkplug ซึ่งดูแลโดยกลุ่มทำงานมาตรฐานเปิดภายใต้มูลนิธิซอฟต์แวร์โอเพนซอร์สระดับโลก (ร่วมผลักดันโดย Arlen Nipper ผู้ร่วมคิดค้น MQTT) ให้คำตอบผ่านกลไกที่วงการเรียกว่า Birth Certificate และ Death Certificate:

• Birth Certificate (NBIRTH) — อุปกรณ์ที่เพิ่งออนไลน์จะประกาศตัวพร้อมรายการ metric ทั้งหมดที่ตัวเองจะส่ง พร้อมชนิดข้อมูลและหน่วยวัด ทำให้ระบบปลายทางรู้ทันทีว่ามีข้อมูลใหม่ใช้ได้ (Immediate Discovery)
• Death Certificate (NDEATH) — เมื่ออุปกรณ์หลุด ข้อมูลเก่าจะถูก mark ว่าหมดอายุ ไม่ให่ dashboard โชว์ค่า stale ว่าเป็นค่าปัจจุบัน (State Awareness)
• Report by Exception — ส่งเฉพาะเมื่อค่าเปลี่ยน ลดปริมาณข้อมูลบนเครือข่ายได้อย่างมาก

4 หลักการออกแบบที่ต้องยึดให้เหนียว

UNS ต่างจาก SCADA/Historian ธรรมดาอย่างไร

คำถามที่เจอบ่อยคือ “เรามี SCADA กับ Historian อยู่แล้ว ต้องมี UNS ทำไม?” คำตอบคือทั้งสามอย่างทำหน้าที่ต่างกัน: SCADA เป็นระบบ ควบคุมและเฝ้าดู, Historian เป็นคลัง เก็บข้อมูลย้อนหลัง ส่วน UNS เป็นชั้น แจกจ่ายข้อมูลเชิงบริบทแบบเรียลไทม์ที่ทุกระบบมาใช้ร่วมกัน — SCADA เองก็ publish ข้อมูลขึ้น UNS ได้ กลายเป็นผู้ผลิตข้อมูลรายหนึ่ง ไม่ใช่ศูนย์กลางจุดเดียวอีกต่อไป

แผนเริ่มต้นใช้งานจริงใน 5 ขั้นตอน

1. ทำ Data Source Inventory — สำรวจว่ามี PLC, มิเตอร์, เครื่องจักรกลุ่มไหนบ้างที่จะเป็นผู้ผลิตข้อมูล พร้อมโปรโตคอลที่แต่ละตัวใช้ (Modbus, OPC UA, EtherCAT)
2. ออกแบบ Topic Hierarchy — ตกลงโครงสร้าง enterprise/site/area/line/cell ให้ตรงกับโครงสร้างธุรกิจจริง อย่าลอกมาจากโรงงานอื่นแบบไม่ปรับ
3. วาง MQTT Broker + ความปลอดภัย — วาง broker ใน DMZ คั่นระหว่างเครือข่าย OT กับ IT เปิด TLS encryption และควบคุมสิทธิ์ topic ละเอียดระดับ read/write
4. เริ่มจากไลน์นำร่อง 1 ไลน์ — ต่อ IIoT Gateway เข้ากับ PLC ของไลน์นั้น ให้ publish ข้อมูลขึ้น UNS แทนการรื้อระบบเดิม (Legacy ยังทำงานต่อได้ parallel กัน)
5. ต่อผู้บริโภคข้อมูลทีละระบบ — พอ hub มีข้อมูลจริง ค่อยต่อ OEE dashboard, ระบบพยากรณ์ หรือ AI ตรวจคุณภาพเข้ามา subscribe ทีละตัว วัดผลก่อนขยาย

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

Key Takeaways

• UNS เปลี่ยนสถาปัตยกรรมข้อมูลโรงงานจาก point-to-point (N×(N−1)/2 การเชื่อมต่อ) เป็น hub-and-spoke ผ่าน MQTT Broker จุดเดียว
• โครงสร้าง topic จัดตามลำดับชั้น ISA-95 (enterprise → site → area → line → cell) ทำให้ข้อมูลมีบริบทเชิงธุรกิจ ไม่ใช่ tag ดิบไร้ความหมาย
• Sparkplug B เติมชั้นความหมายที่ MQTT เปล่าไม่มี: Birth/Death Certificate, ชนิดข้อมูล/หน่วย และ report by exception
• 4 หลักการหลัก: Edge-Driven, Report by Exception, Open Architecture, Lightweight — ขาดข้อใดข้อหนึ่งจะเสียประโยชน์ของ UNS ไปเยอะ
• SCADA, Historian และ UNS ทำหน้าที่ต่างกัน ไม่ใช่ตัวแทนกัน — SCADA ก็เป็นผู้ผลิตข้อมูลรายหนึ่งบน UNS ได้
• เริ่มนำร่อง 1 ไลน์ ใช้ IIoT Gateway publish แทนรื้อระบบเดิม แล้วค่อยขยาย — ไม่ต้องลงทุนรื้อทั้งโรงงานในคราวเดียว
• ความปลอดภัยต้องออกแบบตั้งแต่วันแรก: broker ใน DMZ, TLS, สิทธิ์ topic แบบ read/write แยกรายบุคคล/ระบบ