EP.6 ออกแบบสถาปัตยกรรมระบบ IoT: อุปกรณ์ เกตเวย์ คลาวด์ แอป ใครทำหน้าที่อะไร

📘 ซีรีส์ออกแบบ IoT Product · EP.6/70 · บทที่ 1: ภาพรวมและสเปกสินค้า

ตอนนี้ตอบคำถามว่า ระบบ IoT หนึ่งระบบมีอะไรบ้าง และตรรกะสำคัญควรอยู่ตรงไหน ใน EP.5 เราได้เพดานงบ BOM ราว 30% ของราคาขาย วันนี้เอาสเปกกับงบนั้นมาวาดเป็นภาพทั้งระบบ

แผนภาพระบบ 5 ชั้น

คนทำต้นแบบมักข้ามขั้นนี้ เพราะบนโต๊ะมีแค่บอร์ดตัวเดียว แต่พอขายจริงต้องรองรับหลายฟาร์มและวันที่ทุกอย่างพัง การย้ายหน้าที่จากคลาวด์ลงมาที่เครื่องหลังผลิตแล้วแพงกว่าคิดให้ถูกตั้งแต่ต้นหลายเท่า เพราะแก้ได้แค่ผ่านอัปเดตเฟิร์มแวร์

เซนเซอร์ / แอคชูเอเตอร์    รับรู้ / ลงมือทำ (แอคชูเอเตอร์ เช่น รีเลย์ ไฟ เสียง)
        │
ไมโครคอนโทรลเลอร์ (MCU)   อ่านค่า ตัดสินใจเบื้องต้น เก็บข้อมูลชั่วคราว
        │
การสื่อสาร                Wi-Fi / เซลลูลาร์ / วิทยุกำลังต่ำ
        │
เกตเวย์ (มีหรือไม่ก็ได้)   รวมสัญญาณหลายเซนเซอร์แล้วส่งต่อ
        │
คลาวด์                    รับ → เก็บ → กฎแจ้งเตือน → ส่งคำสั่งกลับ
        │
ผู้ใช้                     LINE OA / เว็บดูกราฟ / แอป

ตรรกะอยู่ที่ edge หรือ cloud

Edge คือประมวลผลที่ตัวเครื่องหรือเกตเวย์ Cloud คือบนเซิร์ฟเวอร์ คำถามตัดสินง่ายที่สุดคือ ถ้าเน็ตหลุด 3 ชั่วโมง ฟังก์ชันนี้ยังต้องทำงานไหม

• ต้องอยู่ที่ edge: อ่านค่าและบันทึกต่อเนื่อง (ช่วงเน็ตหลุดคือช่วงที่ลูกค้าอยากรู้ที่สุด)
• ควรอยู่ที่ cloud: ตรวจว่าเครื่องเงียบ ส่งแจ้งเตือนหลายคน กราฟย้อนหลัง

ไฟดับทั้งบ้าน: เครื่องที่ดับบอกไม่ได้ว่าตัวเองดับ

เครื่องมีแบตสำรองก็จริง แต่ ไฟดับทั้งบ้าน เราเตอร์ก็ดับด้วย เครื่องวัดและเก็บข้อมูลต่อได้ แต่ส่งอะไรออกไปไม่ได้ ทางแก้คือให้ คลาวด์จับ "ความเงียบ" แทน ด้วย 2 กลไกคู่กัน

1. Heartbeat — เครื่องส่งสัญญาณ "ยังอยู่" เป็นระยะ ถ้าคลาวด์ไม่ได้รับเกินเวลาที่ตั้งก็แจ้งว่าเครื่องเงียบ
2. MQTT Last Will — ตอนเชื่อมต่อ เครื่องฝากข้อความ "พินัยกรรม" ไว้กับ broker (เซิร์ฟเวอร์กลางของ MQTT) ตามสเปก MQTT ของ OASIS ถ้าการเชื่อมต่อขาดโดยไม่บอกลา รวมถึงเงียบเกินเวลา keep-alive broker จะประกาศข้อความนั้นแทน (ลงลึกใน EP.22)

ถ้าต้องรู้ทันทีแม้ไฟดับ ต้องใช้ซิมเซลลูลาร์หรือให้เราเตอร์ต่อ UPS

4 เรื่องที่ต้องวางตั้งแต่วันแรก

• เส้นทางข้อมูลขาขึ้น — ข้อมูลที่ค้างช่วงเน็ตหลุดส่งย้อนหลังพร้อมเวลาที่วัดจริง ไม่ใช่เวลาที่ส่ง
• คำสั่งย้อนกลับ — เก็บ "ค่าที่ควรเป็น" ไว้บนคลาวด์ให้เครื่องดึงไปใช้เมื่อกลับมาออนไลน์
• อัปเดตเฟิร์มแวร์ผ่านอากาศ (OTA) — เผื่อแฟลชเก็บเฟิร์มแวร์ 2 ชุดและทางถอยกลับ
• ความปลอดภัย — ทุกเครื่องมีตัวตนและกุญแจของตัวเอง ห้ามใช้รหัสผ่านชุดเดียวกันทุกเครื่อง (ลงลึกใน EP.51)

Build vs Buy: ทีมเล็กควรสร้างเองเฉพาะส่วนที่ทำให้สินค้าต่างจากคนอื่น คือเฟิร์มแวร์ ที่เหลือใช้ของสำเร็จ เช่น โมดูลไร้สายที่ผ่านการรับรองแล้วและ API ของ LINE OA และถามไว้ว่าย้ายออกได้ไหมถ้าผู้ให้บริการปิดตัว

ลองใช้กับโปรเจกต์ตัวอย่าง: ตัวเฝ้าโรงเห็ด

เทียบ 2 แบบ (ก) เครื่องละโรงเรือน ต่อ Wi-Fi บ้านตรงเข้าคลาวด์ กับ (ข) เซนเซอร์ไร้สายกำลังต่ำในแต่ละโรงเรือน + เกตเวย์ 1 ตัวที่บ้าน

การตัดสินใจสำหรับรุ่นแรก: เลือกแบบ (ก) เหตุผลมี 3 ข้อ

1. กลุ่มเป้าหมายมี 1–5 โรงเรือน และตั้งสมมติฐานว่ามีบ้านติดโรงเรือนที่มี Wi-Fi
2. สเปกกำหนดติดตั้งไม่เกิน 15 นาที (ตั้ง Wi-Fi + ผูก LINE ไม่เกิน 5 นาที) แบบ (ก) ไม่ต้องจับคู่อุปกรณ์
3. งบ BOM ราว 30% ของราคาขาย ต้องแบ่งให้เซนเซอร์และส่วนแบ่งเกตเวย์ในแบบ (ข) และล็อตแรก 200 ชุดยังไม่ควรทำอุปกรณ์ 2 แบบพร้อมกัน

แบบ (ก) ต้องมีปลั๊กไฟและสัญญาณ Wi-Fi ถึงจุดติดตั้ง ต้องเช็กกับฟาร์มจริง ถ้าฟาร์มจำนวนมากทำไม่ได้ ให้ย้อนมาพิจารณาแบบ (ข) หรือซิมเซลลูลาร์ (เปรียบเทียบใน EP.21)

เช็กลิสต์ก่อนไปตอนถัดไป

• วาด block diagram ของสินค้าคุณลงกระดาษแผ่นเดียว แล้วตัดสินใจว่ารุ่นแรกมีเกตเวย์หรือไม่
• ถ้าเน็ตหลุด 3 ชั่วโมง ฟังก์ชันไหนยังต้องทำงาน และข้อมูลช่วงนั้นอยู่ที่ไหน
• ถ้าไฟดับทั้งบ้าน ใครรู้ภายในกี่นาที และข้อความแจ้งเตือนเขียนอย่างไรไม่ให้เคลมเกิน
• ถ้าเฟิร์มแวร์ใหม่มีบั๊ก เครื่องถอยกลับเองได้ไหม

ตอนต่อไป — EP.7: อิเล็กทรอนิกส์ที่คนทำ IoT ต้องรู้ (1): แรงดัน กระแส กฎของโอห์ม และไฟ 3.3V กับ 5V

อยากให้ช่วยดูภาพรวมระบบ IoT ของคุณก่อนลงมือสร้าง ดูบริการออกแบบเฉพาะงานได้ที่ /iot หรือ ปรึกษาฟรี และทัก LINE @spvtech ได้เลย