บทเรียน 1.1 — Virtual Device, Digital Twin และโลกของเฟิร์มแวร์จริง

เป้าหมาย

เมื่อจบบทเรียนนี้ คุณจะ

1. แยกความหมายของ Physical Device, Virtual Device, Digital Twin Platform และ Host ด้วยคำพูดของตัวเอง
2. อธิบายว่า Bitstream (UART/บอร์ด) กับ Simulator เป็นเส้นทาง live ที่ใช้ทีละเส้น และบอกเหตุผลที่ไม่ผสมกัน
3. ตัดสินใจว่าสถานการณ์ทดสอบหนึ่งใช้ Twin/Simulator ได้พอ หรือต้องยืนยันบนบอร์ดจริง พร้อมเหตุผล

ก่อนเริ่ม

• บทเรียนแรกของหลักสูตรนี้ — ไม่บังคับผ่านบทเรียนก่อนหน้าในคอร์สนี้ (แต่ต้นฉบับแนะนำให้ผ่าน หลักสูตร Firmware SDK หรือมีพื้นฐาน C/MCU/MQTT เทียบเท่ามาก่อน)
• ไม่ต้องใช้บอร์ด — บทเรียนเชิงแนวคิดล้วน ยังไม่บังคับสร้าง Virtual Device เต็มรูป
• ทำได้ด้วยโหมด Simulator ของ Bitstream Studio (ถ้ามี extension) หรือบอร์ด TESAIoT PSoC Edge DevKit

ดูของจริงก่อน — ทำไมต้องมี Digital Twin

การพัฒนาเฟิร์มแวร์ IoT / Edge AI วันนี้มักมีเซ็นเซอร์หลายตัว, RTOS หลาย task, connectivity (Wi‑Fi/MQTT/BLE) และโฮสต์ดูค่าแบบเรียลไทม์ — ถ้าทดสอบทุกเคสบนบอร์ดจริงอย่างเดียว จะเจอต้นทุนสูง เวลาช้า และความเสี่ยงต่อฮาร์ดแวร์

Key phrase: Twin ไม่ได้แทนที่บอร์ด 100% — มันเป็น สะพาน ระหว่างทฤษฎีเฟิร์มแวร์กับการทดสอบที่ทำซ้ำได้

แนวคิด — Virtual Device เทียบกับ Digital Twin

Physical Device  ≈  "ของจริงบนโต๊ะ"
Virtual Device   ≈  "โมเดลอุปกรณ์หนึ่งเครื่องในซอฟต์แวร์"
Digital Twin     ≈  "โรงงานจำลองทั้งระบบ" (โมเดล + สื่อสาร + จอ + สคริปต์ + cloud sim)

แนวคิด — สถาปัตยกรรมเป็นชั้น (conceptual engines)

Honest mapping: UI ของแต่ละเวอร์ชัน extension อาจต่างกัน — จำบทบาทของชั้น ไม่ใช่จำพิกัดปุ่มทุกจอ

แนวคิด — สองเส้นทาง telemetry (mental model สำคัญ)

ใน Bitstream Studio: Bitstream (UART/บอร์ด) กับ Simulator เป็นเส้นทาง live ที่ใช้ทีละเส้น — ไม่ผสมใน UI

Toolbar source = Bitstream  →  COM open  →  samples origin: uart
Toolbar source = Simulator →  COM closed →  samples origin: sim

แนวคิด — ท่อข้อมูล (data pipeline)

[Source]  board sensors หรือ virtual/sim sensors
        ▼
[Firmware Logic]  — filter · window · decide · encode
        ▼
[Communication]   — UART / MQTT / BLE
        ▼
[Twin Host]       — decode · state · route
        ├─► Visualization (Telemetry / Studio / 3D)
        ├─► External dashboard (Hackathon web-app)
        └─► Cloud / broker (โมดูล 5)

ตัวอย่างสมบูรณ์ — เมื่อไร Twin พอ เมื่อไรต้องบอร์ดจริง

จาก README.md หัวข้อ 5.1 — เวิร์กโฟลว์ที่แนะนำ: พัฒนาบน Twin ก่อน ใช้ชุดเทสเดียวกันให้มากที่สุด แล้วยืนยันรอบสุดท้ายบนฮาร์ดแวร์จริง

ฝึกเติม/แล็บ

แล็บ: แผนที่สถาปัตยกรรม Twin

• แยกความหมาย Physical Device / Virtual Device / Digital Twin ด้วยคำพูดของตัวเอง
• วาดหรือกรอกแผนภาพสถาปัตยกรรมตามแนวคิด engine ที่เรียนมา
• ฝึกตัดสินใจจากตาราง test decision: สถานการณ์ไหนใช้ Twin พอ สถานการณ์ไหนต้องบอร์ดจริง

เช็กความเข้าใจ

1. "แบบจำลองซอฟต์แวร์ของอุปกรณ์หนึ่งตัว ทั้งพิน เซ็นเซอร์ สถานะ และพฤติกรรมตอบสนอง" คือข้อใด
2. ทำไม Bitstream Studio ให้ใช้ Bitstream หรือ Simulator ทีละเส้น
3. สถานการณ์ใดที่บทเรียนระบุว่า Twin "ไม่แทน" และต้องใช้บอร์ดจริง

ไปต่อ

• Digital Twin คือสภาพแวดล้อมที่รวม Virtual Device + การสื่อสาร + visualization + สคริปต์
• Bitstream กับ Simulator เป็นเส้นทาง live ที่ใช้ทีละเส้นเสมอ
• เลือกใช้ Twin ก่อน แล้วยืนยันรอบสุดท้ายบนบอร์ดจริงสำหรับ RF/analog/พลังงาน/pin map
• พร้อมแล้วสำหรับ โมดูล 2 — VS Code สำหรับพัฒนาร่วมกับ Twin

บทเรียนโมดูล 2 →

แหล่งที่มา

"บทเรียน 1.1 — Virtual Device, Digital Twin และโลกของเฟิร์มแวร์จริง" จาก TESA Open Knowledge โดยสมาคมสมองกลฝังตัวไทย
(Thai Embedded Systems Association: TESA) https://github.com/tesaiot/tesa-qualification-program
สัญญาอนุญาต CC BY-NC 4.0

เนื้อหาต้นฉบับโดย ผศ.ดร.สันติ นุราช ภาควิชาวิศวกรรมระบบควบคุมและเครื่องมือวัด คณะวิศวกรรมศาสตร์
มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าธนบุรี (KMUTT) (https://github.com/drsanti) ภายใต้การสนับสนุนของสมาคมสมองกลฝังตัวไทย (TESA)
นำเข้าจาก drsanti/TESAIoT-Courses — C2 (commit 287c218) ภายใต้สัญญาอนุญาต CC BY 4.0

ไม่มีภาพจากบุคคลที่สามในสไลด์ชุดนี้