ทำไมต้องสนใจเรื่องโปรโตคอลการสื่อสาร?
ถ้าคุณเป็นเจ้าของโรงงานหรือวิศวกรที่กำลังจะเอา IoT เข้ามาใช้ในการผลิต สิ่งที่ต้องตัดสินใจตั้งแต่แรกๆ เลยก็คือ “จะให้เครื่องมันคุยกันยังไง” — คำตอบนี้ส่งผลต่อทุกอย่างตั้งแต่ความเร็วในการรับส่งข้อมูล ไปจนถึงค่าใช้จ่ายในการดูแลระบบ
วันนี้เล่าให้ฟังเรื่อง MQTT กับ REST API สองตัวเลือกที่ใช้กันมากในโลก IIoT ว่าแต่ละตัวมันต่างกันยังไง และทำไมเดี๋ยวนี้หลายโรงงานถึงเลือกใช้ MQTT
MQTT คืออะไร?
MQTT (Message Queuing Telemetry Transport) เป็นโปรโตคอลที่ออกแบบมาสำหรับเชื่อมต่ออุปกรณ์ IoT โดยเฉพาะ ถูกพัฒนาขึ้นโดยวิศวกรของ IBM ตั้งแต่ปี 1999 และกลายเป็นมาตรฐานสากลตั้งแต่ปี 2013 จนถึงตอนนี้ MQTT เป็นหนึ่งในโปรโตคอลที่ได้รับความนิยมมากที่สุดในโลก IIoT
หลักการทำงานของ MQTT
MQTT ใช้หลักการที่เรียกว่า Publish/Subscribe (Pub/Sub) — พูดง่ายๆ ก็คือ อุปกรณ์ที่ส่งข้อมูล (Publisher) จะไม่ส่งตรงไปหาใคร แต่ส่งไปที่ Broker ซึ่งเป็นตัวกลาง แล้ว Broker กระจายข้อมูลไปให้อุปกรณ์ที่สนใจ (Subscriber) เอง
องค์ประกอบหลักๆ มีแค่ 4 ตัว:
- Broker — ตัวกลางที่คอยรับข้อมูลแล้วกระจายต่อ
- Publisher — อุปกรณ์ที่ส่งข้อมูล เช่น เซ็นเซอร์วัดอุณหภูมิ
- Subscriber — อุปกรณ์หรือแอปที่รับข้อมูล เช่น Dashboard, SCADA
- Topic — ช่องทางสำหรับส่งข้อมูล เช่น
factory1/sensors/temperature
ทำไม MQTT ถึงเหมาะกับงาน IIoT มากกว่า REST API?
1. ขนาดเล็ก กินแบนด์น้อยมาก
MQTT มี overhead แค่ 2 bytes ต่อ message เทียบกับ REST API ที่ใช้ HTTP Header หลายร้อย bytes ขึ้นไป สำหรับอุปกรณ์ IoT ที่ใช้พลังงานต่ำและเครือข่ายจำกัด ตรงนี้สำคัญมาก
2. Push-based — ข้อมูลมาถึงทันที ไม่ต้องคอยถาม
REST API ทำงานแบบ “ถาม-ตอบ” คือต้องไปขอข้อมูลเรื่อยๆ (polling) ซึ่งเปลืองแบนด์และช้า MQTT จะส่งข้อมูลไปให้ทันทีเมื่อมีการเปลี่ยนแปลง ไม่ต้องคอยถาม
3. ปรับ QoS ได้ตามความต้องการ
MQTT มี 3 ระดับความน่าเชื่อถือในการส่งข้อมูล:
- QoS 0: ส่งแล้วลืม (เหมาะกับข้อมูลที่มากๆ ก็ได้)
- QoS 1: ส่งแน่นอน อาจซ้ำได้ (เหมาะกับงานส่วนใหญ่)
- QoS 2: ส่งแม่นยำที่สุด ไม่ซ้ำ (เหมาะกับงาน critical)
4. รู้ได้ทันทีเมื่ออุปกรณ์หลุด
ถ้าเซ็นเซอร์ตัวไหนดับหรือหลุดออกจากระบบ Broker จะรู้ได้เลย ซึ่งในโรงงานที่ต้องมอนิเตอร์สถานะเครื่องจักรตลอดเวลา ฟีเจอร์นี้ช่วยป้องกันปัญหาได้เยอะ
5. Subscriber ใหม่ก็รู้สถานะปัจจุบันได้ทันที
ข้อมูลล่าสุดจะถูกเก็บไว้ใน Broker พอมี Subscriber ใหม่เข้ามา ก็จะได้รับสถานะปัจจุบันทันที ไม่ต้องรอให้ข้อมูลมาส่งใหม่
เปรียบเทียบตรงๆ กันเลย
| หัวข้อ | MQTT | REST API |
|---|---|---|
| รูปแบบการสื่อสาร | Pub/Sub (Async) | Request/Response (Sync) |
| ขนาด Protocol Overhead | ~2 bytes | 200-1000+ bytes |
| การใช้แบนด์วิดท์ | ต่ำมาก | ปานกลาง-สูง |
| Latency | ต่ำ (milliseconds) | ปานกลาง |
| Real-time capability | ดีมาก (Push-based) | ต้อง Polling |
| ความซับซ้อนในการ implement | ปานกลาง | ต่ำ |
| Scalability (หลาย subscribers) | ดีมาก | ต้องจัดการหลาย connections |
| Battery consumption | ต่ำ | สูงกว่า |
ใช้งานจริงในโรงงานยังไง?
Factory Floor Monitoring
สายการผลิตที่มีเซ็นเซอร์หลายร้อยตัว ถ้าใช้ REST API แบบ polling ซีเซิร์ฟเวอร์จะถูกระเบิดด้วย request จำนวนมาก MQTT รองรับเซ็นเซอร์นับพันตัวบน Broker เดียว โดยแต่ละตัวส่งข้อมูลเมื่อมีการเปลี่ยนแปลงเท่านั้น
ตัวอย่าง Topic ที่ใช้ในโรงงาน:
factory/floor1/lineA/sensors/temperature factory/floor1/lineA/sensors/vibration factory/floor1/lineA/actuators/valve01/status factory/alerts/lineA/overtemperature
SCADA to IIoT Gateway
ระบบ SCADA แบบดั้งเดิมที่ใช้ Modbus หรือ OPC-UA อยู่ สามารถเพิ่ม MQTT Gateway เพื่อ bridge ข้อมูลไปยัง cloud dashboard หรือ analytics platform ได้เลย โดยไม่ต้องแก้ไขระบบ SCADA เดิม
Multi-site Monitoring
องค์กรที่มีหลายโรงงาน MQTT รองรับการ bridging ระหว่าง Broker หลายตัว ดึงข้อมูลจากทุก site มาดูที่ dashboard กลางได้อย่างมีประสิทธิภาพ
เรื่องความปลอดภัย
- TLS/SSL — เข้ารหัสข้อมูลระหว่างส่ง
- Username/Password — ผ่าน Broker
- OAuth 2.0 / JWT — สำหรับระบบที่ต้องการความปลอดภัยสูง
- ACL — ควบคุมว่า client ใดสามารถ publish หรือ subscribe topic ใดได้บ้าง
สรุป: สำหรับโรงงานอัจฉริยะที่ต้องการ real-time monitoring, SCADA integration และ IIoT infrastructure ที่ scale ได้ MQTT ชนะ REST API ในแทบทุกมิติ — ขนาดเล็ก กินแบนด์น้อย ส่งข้อมูลทันที และมีระบบนิเวศใหญ่มากในโลก IIoT ตั้งแต่ Broker อย่าง Mosquitto, HiveMQ, EMQX ไปจนถึง cloud services อย่าง AWS IoT Core, Azure IoT Hub และ Google Cloud IoT Core ที่รองรับ MQTT เป็นมาตรฐานหลัก