รูปแบบการสื่อสารแบบ Polling และ Event-Driven ในระบบ IoT

ไม่ใช่แค่ส่งข้อมูล แต่คือกำหนด “พฤติกรรม” ของระบบทั้งหมด

ในการออกแบบระบบ IoT เรามักมองการสื่อสารเป็นแค่ “ท่อส่งข้อมูล” แต่ในความเป็นจริง มันมากกว่านั้นมาก รูปแบบการสื่อสารที่เราเลือก ไม่ว่าจะเป็น Polling หรือ Event-Driven คือการตัดสินใจพื้นฐานที่กำหนด พฤติกรรมทั้งระบบ ตั้งแต่ต้นจนจบ ว่าจะควบคุมจากศูนย์กลาง หรือปล่อยให้อุปกรณ์ตัดสินใจเอง จะตอบสนองแบบ real-time หรือแบบคาดเดาได้แน่นอน จะประหยัดพลังงาน หรือจะแลกกับความแน่นอนสูงสุด

เพราะฉะนั้น การเลือกโครงสร้างการสื่อสารจึงไม่ใช่เรื่องเทคนิคเล็กๆ แต่เป็นการออกแบบ พฤติกรรมหลัก ของระบบให้สอดคล้องกับงานจริง และนั่นคือเหตุผลที่เราต้องพิจารณาให้เหมาะสมตั้งแต่แรก

ต่อไปนี้ เราจะมาดูกันว่า การออกแบบโครงสร้างการสื่อสารให้เหมาะกับงาน ควรเริ่มจากอะไร และแต่ละแบบเหมาะกับบริบทแบบไหนบ้าง

การออกแบบโครงสร้างการสื่อสารให้เหมาะกับงาน

ในระบบ IoT และ Embedded Communication รูปแบบการสื่อสารหลัก ๆ มี 2 แนวคิดใหญ่:

1. Polling (Request–Response)

2. Event-Driven (Push / Publish)

ทั้งสองแบบไม่มีแบบไหน “ดีกว่าเสมอ”
แต่เหมาะกับบริบทต่างกัน

1️⃣ Polling (Request–Response Model)

ตัวกลาง (Master) เป็นผู้เริ่มการสื่อสารทุกครั้ง

พบได้ในระบบอย่าง Modbus RTU และระบบ PLC อุตสาหกรรมจำนวนมาก

โครงสร้างพื้นฐาน
Master → Request
Slave → Response
(วนลำดับทีละตัว)

จุดแข็งของ Polling

✅ 1. Deterministic

• คำนวณรอบเวลาได้

• คาดเดา latency ได้

✅ 2. ลดการชนกัน (Collision Control)

• มีคนเริ่มพูดคนเดียว

• ไม่มีหลายอุปกรณ์ส่งพร้อมกัน

✅ 3. ตรวจจับอุปกรณ์หายได้ (Supervision)

• ถ้าไม่ตอบภายใน timeout → แจ้ง Fault

✅ 4. Debug ง่าย

• Trace packet ตามลำดับได้ชัด

จุดอ่อนของ Polling

❌ 1. ใช้ Bandwidth ตลอดเวลา

แม้ไม่มีการเปลี่ยนแปลงค่า ก็ยังต้องถาม

❌ 2. Latency ขึ้นกับรอบ Poll

ถ้า Poll ทุก 5 วินาที → เหตุการณ์อาจดีเลย์ 5 วินาที

เทคนิคแก้ปัญหาใน Polling

2️⃣ Event-Driven (Push / Publish Model)

อุปกรณ์ส่งข้อมูลเมื่อ “เกิดเหตุการณ์”

พบได้ในระบบ Cloud และโปรโตคอลอย่าง MQTT

โครงสร้างพื้นฐาน

Node → ส่งเมื่อมีเหตุ
Gateway → รับและประมวลผล

จุดแข็งของ Event-Driven

✅ 1. ประหยัดพลังงาน

• ส่งเฉพาะตอนจำเป็น

✅ 2. Latency ต่ำ

• เหตุการณ์ถูกส่งทันที

✅ 3. เหมาะกับระบบกระจาย (Distributed System)

จุดอ่อนของ Event-Driven

❌ 1. เสี่ยงชนกัน (Collision)

• หลาย Node ส่งพร้อมกัน

❌ 2. ตรวจจับ Node ตายยาก

• ถ้าเงียบ ไม่รู้ว่าปกติหรือพัง (แต่ในระบบ API หรือ MQTT สมัยใหม่ การตรวจจับ device หาย ทำได้ดีมากผ่านกลไก Keep-Alive ทำให้จุดอ่อนนี้ลดลงอย่างมาก)

❌ 3. Timing คาดเดายาก

เทคนิคแก้ปัญหาใน Event-Driven

3️⃣ เปรียบเทียบเชิงวิศวกรรม

4️⃣ ความสำคัญในงานจริง

🏭 งานอุตสาหกรรม / Safety

มักเลือก Polling เพราะ:

• ต้องการ deterministic

• ต้องจับ Fault ได้

• ต้องคำนวณ cycle time ได้

☁️ งาน Smart Home / IoT Cloud

มักเลือก Event-Driven เพราะ:

• ประหยัดพลังงาน

• รองรับอุปกรณ์จำนวนมาก

5️⃣ แนวทาง Hybrid (แนวปฏิบัติที่พบบ่อยที่สุด)

ระบบสมัยใหม่จำนวนมากใช้แบบผสม:

ปกติ → Polling ทุก X วินาที
เมื่อเกิดเหตุ → ส่ง Event ทันที
ถ้าไม่ตอบ → Timeout Alarm

ข้อดี:

• คุมระบบได้

• ตอบสนองเร็ว

• ตรวจจับ Fault ได้

6️⃣ สรุปเชิงออกแบบ

• ถ้าคุณต้องการ “ความนิ่งและคาดเดาได้” → Polling

• ถ้าคุณต้องการ “ความรวดเร็วและประหยัดพลังงาน” → Event-Driven

• ถ้าต้องการทั้งสอง → Hybrid Architecture

แบบไหนดีกว่า?

Polling และ Event-Driven
ไม่ใช่คู่แข่งกัน

แต่เป็น “เครื่องมือ” คนละประเภท
การเลือกขึ้นอยู่กับ:

• ความสำคัญของระบบ

• จำนวนอุปกรณ์

• พลังงาน

• ความต้องการด้านความปลอดภัย

• ความต้องการด้าน latency

• ความคุ้มค่า

การเลือกใช้จึงไม่ใช่คำถามว่า แบบไหนดีกว่า
แต่เป็นคำถามว่า ระบบของคุณต้องการพฤติกรรมแบบใด

ในโลกจริง ระบบที่ออกแบบดีมักเป็น Hybrid Architecture
ที่ใช้จุดแข็งของทั้งสองแนวคิดร่วมกัน

การออกแบบ IoT ที่ดี
ไม่ใช่การเลือกเทคนิคที่ทันสมัยที่สุด

แต่คือการเลือก “รูปแบบพฤติกรรมของระบบ”
ให้สอดคล้องกับความเสี่ยง ข้อจำกัด และเป้าหมายของงาน

เพราะในท้ายที่สุด
สถาปัตยกรรมที่เหมาะสม สำคัญกว่าความซับซ้อนของเทคโนโลยี