PinPrint

MQTT (Message Queuing Telemetry Transport) เป็นโปรโตคอลสื่อสารแบบ lightweight ที่ออกแบบมาเพื่อส่งข้อมูลจากอุปกรณ์ที่มีทรัพยากรจำกัด เช่น เซ็นเซอร์อุณหภูมิ มอเตอร์ หรือ PLC ในโรงงานอุตสาหกรรม โดยใช้สถาปัตยกรรม Publish/Subscribe ที่แยกผู้ส่งและผู้รับออกจากกัน ทำให้ระบบสามารถขยายตัวได้ถึง หลายล้านการเชื่อมต่อพร้อมกัน โดยไม่ต้องเปลี่ยนแปลงโครงสร้าง

สถาปัตยกรรม Publish/Subscribe ทำงานอย่างไร?

ใน MQTT จะมี Broker ทำหน้าที่เป็นศูนย์กลางกระจายข้อความ อุปกรณ์ที่ต้องการส่งข้อมูล (Publisher) จะส่งข้อความไปยังหัวข้อที่เรียกว่า Topic เช่น factory/line1/temp_sensor_01 ส่วนอุปกรณ์ที่ต้องการรับข้อมูล (Subscriber) จะสมัครรับข้อมูลจาก Topic ที่สนใจ ข้อดีคือ Publisher ไม่จำเป็นต้องรู้ว่าใครจะรับข้อมูล ทำให้การเพิ่ม-ลดอุปกรณ์ไม่กระทบกัน

ข้อได้เปรียบหลัก: Publisher และ Subscriber ทำงานแบบ Decoupled ทั้งเชิงพื้นที่ เชิงเวลา และเชิงการซิงโครไนซ์ → ระบบสื่อสารยืดหยุ่นสูง ขยายได้ง่าย ทนต่อการขาดหายของอุปกรณ์บางตัว

QoS (Quality of Service) — ระดับคุณภาพการส่งข้อมูล

MQTT กำหนดระดับ QoS ไว้ 3 ระดับ เพื่อให้ผู้พัฒนาเลือกสมดุลระหว่างความเชื่อถือได้และประสิทธิภาพ

ระดับ QoS ชื่อ การรับประกัน การแลกเปลี่ยนข้อความ
0 At most once ส่งครั้งเดียว ไม่รับประกันถึง (Fire and Forget) 1 ครั้ง (PUBLISH)
1 At least once รับประกันว่าข้อความจะถึงอย่างน้อย 1 ครั้ง (อาจซ้ำ) 2 ครั้ง (PUBLISH + PUBACK)
2 Exactly once รับประกันว่าข้อความจะถึงพอดี 1 ครั้ง ไม่ซ้ำ 4 ครั้ง (PUBLISH + PUBREC + PUBREL + PUBCOMP)

ในโรงงานจริง การเลือก QoS ขึ้นอยู่กับชนิดข้อมูล: ข้อมูลอุณหภูมิที่ส่งทุก 5 วินาทีใช้ QoS 0 ได้ (หากหายไปครั้งเดียวไม่วิกฤต) แต่คำสั่งควบคุมเช่น “หยุดมอเตอร์” ต้องใช้ QoS 2 เพื่อไม่ให้คำสั่งซ้ำหรือหาย

MQTT 5.0 — ฟีเจอร์ใหม่ที่สำคัญ

  • Reason Code: ทุก ACK มีรหัสเหตุผล ทำให้ Debug ง่ายขึ้น (เช่น 0x87 = Not Authorized)
  • Shared Subscription: หลาย Subscriber แบ่งกันรับข้อความจาก Topic เดียว → Load Balancing แบบกระจาย
  • User Properties: เพิ่ม metadata กำหนดเองในข้อความได้ เหมือน HTTP Header
  • Message Expiry: กำหนดอายุข้อความ หาก Broker ไม่ส่งทันเวลา → ข้อความถูกทิ้งอัตโนมัติ
  • Topic Alias: ใช้ตัวเลขแทนชื่อ Topic ยาวๆ → ลดขนาด Header ลงได้มาก

Sparkplug B — มาตรฐานสำหรับโรงงาน

MQTT ดั้งเดิมไม่ได้กำหนดโครงสร้างข้อมูล (Payload) ทำให้แต่ละระบบใช้กันคนละรูปแบบ Sparkplug B แก้ปัญหานี้โดยกำหนด:

  • รูปแบบ Topic Namespace มาตรฐาน: spBv1.0/{group}/{message_type}/{edge_node_id}/{device_id}
  • Payload เป็น Protocol Buffers ที่บีบอัดขนาดเล็กและถอดรหัสเร็ว
  • กลไก Birth/Death Certificate ที่บอกสถานะ Online/Offline ของทุกอุปกรณ์ทันที
  • การจัดการ Stateful Session ทำให้ SCADA รู้ได้ทันทีว่าเซ็นเซอร์ตัวไหนหลุดออกจากระบบ

การเปรียบเทียบ MQTT กับโปรโตคอลอื่น

คุณสมบัติ MQTT HTTP AMQP CoAP
โมเดล Pub/Sub Request/Response Pub/Sub + Queue Req/Resp (UDP)
ขนาด Header 2 bytes ~200–800 bytes 8+ bytes 4 bytes
Transport TCP TCP TCP UDP
การเชื่อมต่อ Persistent Stateless Persistent Connectionless
แบนด์วิดธ์ที่ต้องการ ต่ำมาก สูง ปานกลาง ต่ำ

การใช้งานในโรงงานจริง

ตัวอย่างเช่น โรงงานที่มีเซ็นเซอร์วัดอุณหภูมิ 500 ตัวกระจายอยู่ทั่วโรงงาน แต่ละตัวส่งข้อมูลทุก 10 วินาที หากใช้ HTTP จะต้องสร้าง Connection ใหม่ทุกครั้ง (Overhead ~700 bytes/request × 50 req/s = 35 KB/s เฉพาะ Header) แต่ MQTT เชื่อมต่อครั้งเดียวแล้วส่ง Payload เพียง 2 bytes Header + ข้อมูลจริง → ประหยัดแบนด์วิดธ์กว่า 90%

Key Takeaways

  1. MQTT ใช้สถาปัตยกรรม Pub/Sub ที่แยก Publisher จาก Subscriber ผ่าน Broker กลาง → ขยายระบบได้ถึงล้านการเชื่อมต่อ
  2. QoS 3 ระดับ (0/1/2) ให้เลือกสมดุลระหว่างความเชื่อถือและประสิทธิภาพตามความสำคัญของข้อมูล
  3. Header เพียง 2 bytes ทำให้ MQTT เหมาะกับอุปกรณ์ที่มีแบนด์วิดธ์ต่ำและพลังงานจำกัด
  4. Sparkplug B เพิ่มมาตรฐาน Payload และการจัดการสถานะอุปกรณ์ → เหมาะกับ SCADA และ IIoT
  5. MQTT 5.0 เพิ่ม Shared Subscription, Reason Code และ Message Expiry ที่แก้จุดอ่อนเดิมได้หมด
  6. การเชื่อมต่อ Persistent ลด Overhead ได้กว่า 90% เมื่อเทียบกับ HTTP ในสถานการณ์ส่งข้อมูลบ่อย
  7. ความปลอดภัย อาศัย TLS 1.2/1.3 + X.509 Certificate + Username/Password หรือ Client Certificate Authentication
PinPrint