หลายโรงงานที่เริ่มทำ IIoT มักเจอคำถามเดียวกัน คือ “เราควรวิเคราะห์ข้อมูลที่ Edge หรือส่งขึ้น Cloud ดี” คำตอบที่งานวิจัยและการใช้งานจริงชี้ตรงกันคือ ไม่ต้องเลือกอย่างใดอย่างหนึ่ง เพราะระบบ IIoT สมัยใหม่ควรเป็นสถาปัตยกรรมแบบหลายชั้น (Multi-tier) ที่เรียกชั้นกลางระหว่างเครื่องจักรกับคลาวด์ว่า Fog Computing — ชั้นคำนวณที่กระจายอยู่ตามโหนดเกตเวย์และเซิร์ฟเวอร์ระดับโรงงาน ก่อนข้อมูลจะไหลขึ้นสู่คลาวด์จริง

บทความนี้เจาะลึกว่า Fog Computing ทำงานอย่างไร ต่างจาก Edge Computing ตรงไหน และโรงงานควรออกแบบชั้น Fog อย่างไรให้คุ้มค่ากับการลงทุน

หลักการทำงานของ Fog Computing

แนวคิด Fog Computing เกิดจากข้อจำกัดของ Cloud Computing แบบศูนย์กลาง คือ หากส่งข้อมูลดิบจากเซ็นเซอร์ทุกตัวขึ้นคลาวด์ แบนด์วิดธ์และค่า latency จะบานปลายทันทีเมื่อจำนวนอุปกรณ์เพิ่มขึ้นเป็นพันเป็นหมื่นตัว Fog Computing จึงแทรก “ชั้นหมอก” ของทรัพยากรคำนวณลงไประหว่างอุปกรณ์ปลายทางกับคลาวด์ ทำหน้าที่ 3 อย่างหลักคือ

  • รวบรวมและกรองข้อมูล (Aggregation) — รับข้อมูลจากหลาย ๆ Edge Device ในโซนเดียวกัน บีบอัด ลดความถี่ และส่งเฉพาะข้อมูลที่มีค่าขึ้นคลาวด์
  • ประสานงานระหว่างโหนด (Orchestration) — จัดสรรงานคำนวณให้เหมาะกับทรัพยากรของแต่ละโหนดในโรงงาน
  • ทำหน้าที่เป็นสะพาน (Bridge) — แปลงโปรโตคอลจาก Modbus TCP, OPC UA ให้เป็น MQTT หรือ REST API ก่อนส่งออกสู่ภายนอก
แผนภาพสถาปัตยกรรม Fog Computing แสดงชั้น Cloud ชั้น Fog และอุปกรณ์ปลายทาง
สถาปัตยกรรม Fog Computing: ชั้นหมอกของโหนดคำนวณ (Fog Nodes) ทำหน้าที่รวบรวมและกรองข้อมูลจากอุปกรณ์ก่อนส่งขึ้นคลาวด์ (ภาพ: Wikimedia Commons, CC BY 4.0)

Fog vs Edge vs Cloud — ตารางเปรียบเทียบ

ประเด็น Edge Computing Fog Computing Cloud Computing
ตำแหน่ง บนหรือใกล้เครื่องจักรโดยตรง โหนดกลางระหว่าง Edge กับ Cloud ดาต้าเซ็นเตอร์ภายนอก
Latency ต่ำสุด (ระดับมิลลิวินาที) ต่ำ แต่สูงกว่า Edge สูง (อาจถึงหลายสิบมิลลิวินาที)
การประมวลผล ข้อมูลเรียลไทม์บนเครื่อง รวมกรองข้อมูลหลาย Edge ก่อนส่งต่อ การวิเคราะห์เชิงลึกและเก็บถาวร
ขนาดระบบ ระดับเครื่อง/เซลล์เดียว ระดับโรงงาน/หลายไลน์ผลิต ระดับองค์กร/หลายสาขา
กรณีใช้งาน Predictive Maintenance, Machine Vision, ควบคุมเรียลไทม์ เชื่อมหลายไลน์, จัดการข้อมูลหลายไซต์, Analytics กลาง ERP, Big Data Analytics, AI Training
การพึ่งพาคลาวด์ น้อยที่สุด ปานกลาง — ใช้คลาวด์เพื่อเก็บและวิเคราะห์เพิ่ม สูง — เป็นศูนย์กลางทั้งหมด

ตัวอย่างการใช้งานจริงในโรงงาน

สมมติโรงงานอาหารแช่แข็งมี 3 ไลน์ผลิต รวม 500 จุดวัดอุณหภูมิ (ความละเอียด 1 วินาที) และเพิ่มระบบวิเคราะห์แรงสั่นสะเทือนของมอเตอร์ตู้แช่อีก 80 ตัว ถ้าส่งข้อมูลดิบทั้งหมดขึ้นคลาวด์จะได้ปริมาณข้อมูลมหาศาลและเสียแบนด์วิดธ์โดยเปล่าประโยชน์ โจทย์แบบนี้คือจุดที่ Fog Computing เหมาะที่สุด:

  1. ชั้น Edge — เกตเวย์ประจำไลน์อ่านค่า Modbus TCP / OPC UA จาก PLC และเซ็นเซอร์ ทำ FFT หาความผิดปกติเบื้องต้นทันที (Latency < 10 ms)
  2. ชั้น Fog — เซิร์ฟเวอร์กลางของโรงงานรวมข้อมูลจากทั้ง 3 ไลน์ เก็บ Time-series Database ภายใน 90 วัน ทำ Dashboard และ Anomaly Detection ระดับโรงงาน
  3. ชั้น Cloud — รับเฉพาะข้อมูลสรุป (เช่น ค่าเฉลี่ยราย 5 นาที, เหตุการณ์ Alarm) เพื่อรายงานผู้บริหารและฝึกโมเดล AI ระดับกลุ่มบริษัท

แนวทางนี้คล้ายกับงานที่ Honey Corporation เคยติดตั้งระบบ IoT Monitoring ให้ลูกค้ากลุ่มค้าปลีกและคลังสินค้า ที่ต้องดึงข้อมูลอุณหภูมิตู้แช่หลายพันจุดจากหลายสาขา การวางเกตเวย์กลางเพื่อรวบรวมข้อมูลก่อนส่งขึ้นคลาวด์ช่วยลดปริมาณข้อมูลที่ต้องส่งออกได้มากกว่า 90% และทำให้ Dashboard ยังใช้งานได้แม้อินเทอร์เน็ตขัดข้องชั่วคราว

แผนภาพการไหลของข้อมูลในสถาปัตยกรรม Fog Computing
การไหลของข้อมูลแบบหลายชั้น: ข้อมูลดิบถูกกรองทีละชั้นก่อนขึ้นสู่คลาวด์ (ภาพ: Wikimedia Commons, CC BY 4.0)

ปัญหาที่ต้องออกแบบให้รอบคอบ

Fog Computing ไม่ใช่ยาวิเศษ มีข้อแลกเปลี่ยนที่วิศวกรต้องชั่งน้ำหนัก:

  • ความซับซ้อนเพิ่มขึ้น — ยิ่งมีหลายชั้น ยิ่งต้องจัดการเรื่อง Version, Security Patch และการ Monitor หลายจุด
  • ความปลอดภัยต้องครบทุกชั้น — โหนด Fog อยู่ในโรงงานและเชื่อมกับภายนอก จึงต้องมี Network Segmentation และการเข้ารหัสข้อมูลระหว่างส่ง
  • การจัดการข้อมูล — ต้องกำหนดนโยบายชัดว่าข้อมูลชุดใดอยู่ที่ Fog, ชุดใดขึ้น Cloud, เก็บนานแค่ไหน

Key Takeaways

  1. Fog ไม่ใช่คู่แข่งของ Edge — Fog คือชั้นกลางที่ขยายความสามารถของ Edge ให้รองรับทั้งโรงงาน ไม่ใช่เพียงเครื่องเดียว
  2. ตัวชี้วัดสำคัญคือ Latency และ Bandwidth — งานควบคุมเรียลไทม์อยู่ที่ Edge, การรวมข้อมูลหลายไลน์อยู่ที่ Fog, การวิเคราะห์เชิงลึกอยู่ที่ Cloud
  3. ลดข้อมูลขาออกได้ 90%+ — การกรองข้อมูลที่ชั้น Fog ช่วยลดการใช้แบนด์วิดธ์และทรัพยากรคลาวด์อย่างมีนัยสำคัญ
  4. รองรับสถานการณ์ออฟไลน์ — Fog Node เก็บข้อมูลและทำงานต่อได้แม้อินเทอร์เน็ตหลุด ซึ่งเป็นจุดแข็งเหนือสถาปัตยกรรม Cloud-only
  5. ความปลอดภัยต้องออกแบบทุกชั้น — ทั้ง Segmentation, การเข้ารหัส และการจัดการสิทธิ์การเข้าถึงระหว่างโหนด
  6. เริ่มจากไลน์นำร่องก่อน — ทดลองกับ 1–2 ไลน์ผลิต วัดผลด้าน Latency และปริมาณข้อมูลจริง ก่อนขยายทั้งโรงงาน

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

ทีมงานของเรามีความเชี่ยวชาญด้านระบบ IIoT และสถาปัตยกรรม Edge–Fog–Cloud พร้อมออกแบบและติดตั้งระบบให้เหมาะกับธุรกิจของคุณ ตั้งแต่ระดับเซ็นเซอร์จนถึงแดชบอร์ดผู้บริหาร

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