PinPrint
ระบบเครือข่าย IIoT ในโรงงานอุตสาหกรรม
ระบบเครือข่าย IIoT ที่ใช้ MQTT เชื่อมต่อเซ็นเซอร์และอุปกรณ์อุตสาหกรรม (ภาพประกอบ)

MQTT: โปรโตคอล Pub/Sub ที่ขับเคลื่อนการสื่อสารเซ็นเซอร์หลายล้านตัวในโรงงานอัตโนมัติ

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

ในปี 2025-2026 MQTT ได้กลายเป็นโปรโตคอลหลักของระบบ IIoT ทั่วโลก โดยเวอร์ชันล่าสุด MQTT 5.0 เพิ่มความสามารถสำคัญ เช่น Reason Codes, Shared Subscriptions, Message Expiry และ Topic Aliases ที่ช่วยแก้ปัญหาด้าน reliability และ scalability ที่เวอร์ชัน 3.1.1 ไม่สามารถรองรับได้

สถาปัตยกรรม Publish/Subscribe: หัวใจของ MQTT

ต่างจากโปรโตคอลแบบ Request/Response แบบเดิม MQTT ใช้รูปแบบ Pub/Sub ที่ผู้ส่ง (Publisher) ไม่จำเป็นต้องรู้ว่าผู้รับ (Subscriber) คือใคร ทุกอย่างผ่านศูนย์กลางที่เรียกว่า MQTT Broker ซึ่งทำหน้าที่กรองและส่งต่อข้อความตามหัวข้อ (Topic) ที่กำหนด

ตัวอย่าง Topic ในโรงงานอุตสาหกรรม:

  • factory/line-A/temperature/sensor-01 — อุณหภูมิจากเซ็นเซอร์ตัวที่ 1 ของสายการผลิต A
  • factory/line-A/vibration/motor-03 — ค่าการสั่นสะเทือนของมอเตอร์ 3
  • factory/line-B/energy/meter-main — การใช้พลังงานของสายการผลิต B

การใช้ Topic Hierarchy แบบนี้ ทำให้ Subscriber สามารถ subscribe เฉพาะข้อมูลที่ต้องการ เช่น factory/+/temperature/# เพื่อรับทุกค่าอุณหภูมิจากทุกสายการผลิต

QoS (Quality of Service): การรับประกันการส่งมอบ

MQTT กำหนดระดับ QoS 3 ระดับ เพื่อให้เลือกใช้ตามความสำคัญของข้อมูล:

ระดับ QoS การรับประกัน Handshake กรณีใช้งานในโรงงาน
QoS 0 At most once (ส่งแล้วลืม) 1 ครั้ง (PUBLISH) อุณหภูมิแวดล้อม ความชื้นที่อัปเดตทุก 10 วินาที
QoS 1 At least once (รับประกันถึง) 2 ครั้ง (PUBLISH + PUBACK) ค่าการสั่นสะเทือน สถานะเครื่องจักร ที่ต้องไม่หาย
QoS 2 Exactly once (ไม่ซ้ำไม่หาย) 4 ครั้ง (PUBLISH → PUBREC → PUBREL → PUBCOMP) คำสั่งควบคุม, Alarm event, การตัดสินใจ critical

MQTT 5.0: ความก้าวหน้าที่เปลี่ยนเกม IIoT

เวอร์ชัน 5.0 ซึ่งเป็นมาตรฐานปัจจุบัน เพิ่มฟีเจอร์ที่สำคัญต่อระบบอุตสาหกรรม:

  • Reason Codes — Broker ส่งรหัสเหตุผลกลับเสมอ เช่น “Quota Exceeded” หรือ “Topic Mismatch” แทนการตัดการเชื่อมต่อโดยไม่บอกเหตุผล ช่วย debugging ได้เร็วขึ้น
  • Shared Subscriptions — หลาย Subscriber แบ่งกันรับข้อความจาก Topic เดียวกันแบบ Load Balancing เหมาะกับระบบประมวลผลข้อมูลที่มีปริมาณมาก
  • Message Expiry Interval — กำหนดอายุข้อความ เช่น ข้อมูลเซ็นเซอร์ที่เก่ากว่า 30 วินาทีจะถูก discard โดยอัตโนมัติ ป้องกันการประมวลผลข้อมูลเก่า
  • Topic Aliases — แทนที่ Topic string ยาวๆ ด้วยตัวเลข ลด overhead บนเครือข่ายที่แบนด์วิดธ์จำกัด เช่นเครือข่ายเซลลูลาร์
  • Server Disconnect — Broker สามารถบอกเหตุผลการตัดการเชื่อมต่อ แทนการหายไปแบบเงียบๆ
วงจรอิเล็กทรอนิกส์และการเชื่อมต่อข้อมูลในระบบอุตสาหกรรม
การเชื่อมต่อข้อมูลระดับฮาร์ดแวร์ที่ MQTT ช่วยจัดการในระดับโปรโตคอล (ภาพประกอบ)

Sparkplug B: มาตรฐานสำหรับ IIoT ที่ Honey Corporation ใช้

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

  • โครงสร้าง Topic ที่เป็นมาตรฐาน: spBv1.0/{group}/DDATA/{edge_node}/{device}
  • Payload เป็น Protocol Buffers (Protobuf) — เบาและเร็วกว่า JSON
  • State Management: ระบบรู้ว่าอุปกรณ์ใดออนไลน์/ออฟไลน์ผ่าน Birth/Death Certificate
  • Auto-discovery: ไม่ต้อง map tag ด้วยมือ เหมาะกับโรงงานที่มีเซ็นเซอร์หลายพันตัว

ทีมงาน Honey Corporation มีประสบการณ์ติดตั้งระบบ IIoT ที่ใช้ MQTT กับ Sparkplug B ในโรงงานอุตสาหกรรม ช่วยให้สามารถเพิ่มเซ็นเซอร์ใหม่เข้าระบบได้โดยอัตโนมัติ โดยไม่ต้องแก้ไข configuration ของ SCADA หรือ dashboard ทุกครั้ง

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

คุณสมบัติ MQTT HTTP/REST OPC UA
รูปแบบการสื่อสาร Pub/Sub (async) Request/Response Client/Server + PubSub
Header overhead ~2 bytes ~200-800 bytes ~50-100 bytes
Real-time Best-effort (ms ถึง s) Polling (s) Configurable (ms)
การรองรับอุปกรณ์ นับหมื่น-แสน จำกัด หลักร้อย-พัน
การใช้งานหลัก Telemetry, Cloud, Edge API, Web Plant floor, SCADA

Security ในระบบ MQTT อุตสาหกรรม

การรักษาความปลอดภัยใน MQTT มีหลายชั้น:

  1. TLS/SSL Encryption — เข้ารหัส payload ทุก message ด้วย TLS 1.3 ที่เร็วและปลอดภัยกว่า TLS 1.2
  2. Client Authentication — ใช้ Username/Password, Client Certificate หรือ OAuth 2.0 สำหรับการยืนยันตัวตน
  3. ACL (Access Control List) — กำหนดว่า client ใด publish/subscribe topic ใดได้บ้าง
  4. Topic-level Authorization — แยกสิทธิ์ระดับ topic เช่น เซ็นเซอร์สายการผลิต A ไม่สามารถอ่านข้อมูลสายการผลิต B ได้

💡 คำแนะนำ: ในโรงงานอุตสาหกรรม ควรใช้ MQTT Broker แบบ Cluster (หลายโหนดทำงานร่วมกัน) เพื่อ High Availability เมื่อ Broker ตัวใดล่ม ระบบยังทำงานต่อได้โดยไม่สูญเสียข้อมูล

Key Takeaways

  • MQTT เป็นโปรโตคอล Pub/Sub lightweight เหมาะกับ IIoT ที่ต้องเชื่อมต่ออุปกรณ์นับหมื่น
  • QoS 3 ระดับ ให้เลือกตามความสำคัญ — QoS 0 สำหรับ telemetry ทั่วไป, QoS 2 สำหรับ critical command
  • MQTT 5.0 เพิ่ม Reason Codes, Shared Subscriptions และ Message Expiry ที่สำคัญต่อระบบขนาดใหญ่
  • Sparkplug B กำหนด payload format มาตรฐาน แก้ปัญหา interoperability ในโรงงาน
  • Topic Hierarchy ช่วยจัดการข้อมูลแบบลำดับชั้น เช่น factory/line/sensor/type
  • TLS 1.3 + ACL เป็นมาตรฐานขั้นต่ำด้านความปลอดภัยสำหรับ MQTT ในโรงงานอุตสาหกรรม
  • MQTT + OPC UA ใช้ร่วมกันได้ — MQTT สำหรับ telemetry ระดับ Cloud, OPC UA สำหรับ plant floor

Honey Corporation พร้อมให้คำปรึกษา

ทีมงานของเรามีความเชี่ยวชาญด้านระบบ IIoT และ MQTT Integration พร้อมออกแบบและติดตั้งระบบ telemetry ที่รองรับอุปกรณ์นับหมื่น เหมาะกับโรงงานและธุรกิจของคุณ

📞 โทร: 09-23242995 | อีเมล: support@honey.co.th
เว็บไซต์: www.honey.co.th

PinPrint