Virtual Device, Digital Twin และโลกของเฟิร์มแวร์จริง

หลักสูตร: พัฒนาเฟิร์มแวร์ร่วมกับ TESA Digital Twin บน VS Code · สถาปัตยกรรม Digital Twin
ระดับ: L3 ทำได้เอง
เวลาโดยประมาณ: 70 นาที (แนวคิด 45 · ฝึก 15 · เช็กความเข้าใจ 10)
อุปกรณ์: ไม่ต้องใช้บอร์ด
ทักษะที่ฝึก: ดิจิทัลทวิน ถึง L2
การจำลองฮาร์ดแวร์และอีมูเลเตอร์ ถึง L1
การทดสอบแบบ SIL และ HIL ถึง L1
ควรเรียนก่อน: ไม่มี
สถานะ: ทดลองใช้ (alpha)

วิดีโอประกอบ

ดูบน YouTube (เปิดในแท็บใหม่)

TESAIoT Digital Twin สมาคมสมองกลฝังตัวไทย (TESA)
TESAIoT Digital Twin Studio สมาคมสมองกลฝังตัวไทย (TESA)

วิดีโอโดย สมาคมสมองกลฝังตัวไทย (TESA) · ดูทั้งชุดใน playlist AIoT Foundation

Course 2 · Module 1
Suggested time: ประมาณ 2 ชั่วโมง (แนวคิด + แผนภาพ + เปิดโฮสต์ดูท่อข้อมูล)
Format: บทเรียนเชิงแนวคิด — ยังไม่บังคับสร้าง Virtual Device เต็มรูป (เริ่มลงมือใน M02 / M03)

Lab · Cheatsheet · ← Table of Contents · M02 →

เป้าหมาย (Learning Outcomes)

เมื่อเรียนจบ คุณควรทำได้ดังนี้:

อธิบายแนวคิด Virtual Device และ Digital Twin ในงาน IoT / Firmware
อธิบายสถาปัตยกรรม TESA Digital Twin Platform เป็นชั้น ๆ ที่นำไปแล็บได้
อธิบายการจำลองสัญญาณ เซ็นเซอร์ พฤติกรรมอุปกรณ์ และ Data Pipeline
ระบุความสัมพันธ์ระหว่าง Firmware จริง กับ Twin Environment — เมื่อไรใช้บอร์ด / เมื่อไรใช้ Simulator / เมื่อไรต้องยืนยันบนฮาร์ดแวร์

โมดูลนี้คือ แผนที่ความคิด ของ Course 2 หากเข้าใจสถาปัตยกรรม Twin แล้ว การติดตั้ง VS Code host (M02) และการสร้าง Virtual Device (M03) จะมีโครงที่ชัด

แนวทาง “พูดแนวคิด แล้วชี้เครื่องมือจริง”
เอกสารหลักสูตรพูดถึง engines ของแพลตฟอร์ม Twin ในระดับสถาปัตยกรรม
ในแล็บ โฮสต์หลักคือ Bitstream Studio + แพ็ก TESAIoT_Hackathon — บทนี้จับคู่แนวคิดกับสิ่งที่คุณเปิดจริงในแล็บ

Read alongside this chapter

เอกสาร	ใช้เมื่อ
Bitstream Studio (Marketplace)	VS Code host — telemetry, Sensor Studio, Simulator, MQTT, 3D preview
TESAIoT Developer Hub	ตัวอย่างเฟิร์มแวร์ / API ที่จะไหลเข้า Twin
TESAIoT_Hackathon	HEX, VSIX, Flasher, `web-app/` dashboards
ternion-3d-assets-free	โมเดล 3D (GLB), texture, cubemap, รูปภาพสำหรับ Twin / Sensor Studio
Course 1 TOC	พื้นฐาน SDK / sensors / MQTT / BLE
Course 1 M05 — Sensor prep	แหล่งข้อมูลที่จะเข้า pipeline
Course 1 M06 — MQTT	ชั้น cloud ที่ Twin จะจำลอง/ทดสอบ
Bluetooth / local path (C1 M07)	ทางเลือก local เมื่อไม่ใช้ Wi‑Fi
Digital Twin — Wikipedia overview	นิยามทั่วไปนอกคอร์ส (อ่านเสริม)

1. Why Digital Twin for Firmware Development

การพัฒนาเฟิร์มแวร์ IoT / Edge AI วันนี้ไม่ใช่แค่ “กะพริบ LED” อีกต่อไป — ระบบมักมี:

เซ็นเซอร์หลายตัว + กรอง/หน้าต่างข้อมูล
RTOS หลาย task
Connectivity (Wi‑Fi / MQTT / BLE)
โฮสต์ดูค่าแบบเรียลไทม์ และบางครั้งคลาวด์

ถ้าทดสอบทุกเคสบนบอร์ดจริงอย่างเดียว จะเจอต้นทุนสูง เวลาช้า และความเสี่ยงต่อฮาร์ดแวร์

Digital Twin ในหลักสูตรนี้คือการสร้าง ตัวแทนดิจิทัลของอุปกรณ์ ในสภาพแวดล้อมเสมือน เพื่อพัฒนา ทดสอบ วิเคราะห์ และสาธิตได้โดยไม่ต้องพึ่งบอร์ดจริงตลอดเวลา

1.1 What Twin Helps You Do

ประโยชน์	ความหมายในแล็บ
จำลองฮาร์ดแวร์	อ่านค่าเซ็นเซอร์/สถานะโดยไม่ต้องต่อทุกพินจริง
ทดสอบ logic ซ้ำได้	สคริปต์เขย่า IMU / กดสวิตช์ / ตัดเน็ต ได้ซ้ำ
ลดความเสี่ยงบอร์ด	เคสขอบทำบน Twin ก่อน flash จริง
เห็นผลทันที	กราฟ / แผง / 3D / dashboard โฮสต์
เตรียมก่อนคลาวด์	ตรวจรูปแบบ Telemetry / topic ก่อนขึ้น broker จริง

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

1.2 Prerequisites from Course 1

Course 2 สมมติว่าคุณรู้จักแล้ว (หรือทบทวนได้):

จาก Course 1	ใช้ใน Course 2 อย่างไร
ชั้น SDK / โดเมนชิป	รู้ว่าโค้ดแอปอยู่ที่ไหน
Sensors + window	ข้อมูลที่จะเข้า Twin / dashboard
MQTT / BLE	ช่องทางที่ Twin และ cloud จะทดสอบ
Capstone patterns	โครง task + indication + connectivity

2. Virtual Device vs Digital Twin

คำ	ความหมายในหลักสูตรนี้
Physical Device	บอร์ด + เซ็นเซอร์จริง (เช่น PSoC Edge kit)
Virtual Device	แบบจำลองซอฟต์แวร์ของ อุปกรณ์หนึ่งตัว — พิน, เซ็นเซอร์, สถานะ, พฤติกรรมตอบสนอง
Digital Twin (Platform)	สภาพแวดล้อมที่รวม Virtual Device + การสื่อสาร + visualization + สคริปต์เหตุการณ์ + (บ่อยครั้ง) MQTT/cloud จำลอง
Firmware Logic	โค้ดตรรกะผลิตภัณฑ์ที่ควรรันได้ทั้งกับ Twin และกับฮาร์ดแวร์ เมื่อแยกชั้น I/O ออกอย่างเหมาะสม
Host / Twin UI	VS Code extension และแอปโฮสต์ที่คุณใช้ดูผล — ในคอร์สนี้หลักคือ Bitstream Studio

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

เป้าหมายออกแบบโค้ดที่ดี:

แยก application logic ออกจากรายละเอียดฮาร์ดแวร์โดยตรงให้มากพอ
สลับเป้าหมาย (Simulator / board / MQTT host) ได้โดยไม่เขียนแอปใหม่ทั้งก้อน

3. TESA Digital Twin Platform Architecture

หลักสูตรอธิบายแพลตฟอร์มเป็นชุด engine ที่ทำงานรอบแกนกลาง — ผู้เรียนไม่ต้องท่องชื่อผลิตภัณฑ์ย่อยทุกตัว แต่ต้องชี้ได้ว่า แต่ละบทบาท อยู่ตรงไหนตอนแล็บ

3.1 Conceptual engines (curriculum map)

                    ┌─────────────────────────────┐
                    │   Development Host (VS Code) │
                    │   Bitstream Studio / tools   │
                    └──────────────┬──────────────┘
                                   │
                                   ▼
┌──────────────┐     ┌─────────────────────────┐     ┌────────────────┐
│ Firmware     │────►│  Digital Twin Engine     │────►│ Visualization  │
│ Logic        │     │  (state · time · events) │     │ Graphics / UI  │
└──────────────┘     └────────────┬────────────┘     └────────────────┘
                                  │
              ┌───────────────────┼───────────────────┐
              ▼                   ▼                   ▼
      Communication         Scripting /           AI Connectivity
      (UART·MQTT·BLE)       Event / Behavior      (optional path)
              │
              ▼
         Cloud / Broker sim · external dashboards

ชั้น (แนวคิด)	หน้าที่	สิ่งที่มักเปิดในแล็บนี้
Digital Twin Engine	จัดการ state ของ Virtual Device, เวลาจำลอง, ประสานเหตุการณ์	สถานะเซ็นเซอร์/โหมดใน Studio · Simulator stream
Communication Engine	ช่องทางข้อมูลระหว่างเฟิร์มแวร์ ↔ โฮสต์ ↔ cloud	UART/bridge, MQTT broker ใน Studio, BLE host ตามรอบ
Graphics / Visualization	กราฟ, แผง, 3D, orientation	Sensor Telemetry · Sensor Studio · 3D rotation preview
User Interaction	อินพุตจากผู้เรียน (ปุ่ม, สคริปต์, โหมด toolbar)	เปลี่ยน Backend Bitstream/Simulator · สั่ง scene · publish คำสั่ง
Scripting & Events	จำลองเหตุการณ์ซ้ำได้	event script / behavior (ลงลึกใน M03) · fault injection (M05)
AI Connectivity (เสริม)	ส่งข้อมูลไปวิเคราะห์ / รับผลกลับ	เส้นทางเตรียมใน Course 1 M05 — ไม่บังคับ M01
Physics (เสริม)	จำลองการเคลื่อนไหว/แรงเมื่อโมเดลต้องการ	ใช้เมื่อโปรเจกต์มีกลไก — ไม่ใช่ทุกแล็บ

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

3.2 Concrete lab stack (what you install)

ชิ้น	บทบาทใน Course 2
Bitstream Studio	VS Code host หลัก — Twin / telemetry / MQTT / 3D
Bitstream Simulator (companion เมื่อใช้โหมด Simulator)	Virtual MCU ที่ฉีด telemetry โดยไม่ต้องเปิด COM
บอร์ด + HEX จาก Hackathon	Physical path — ยืนยันกับของจริง
Hackathon `web-app/`	Dashboard ภายนอกดูท่อ telemetry / MQTT
Developer Hub	ตัวอย่างเฟิร์มแวร์ต้นทาง
ternion-3d-assets-free	GLB / texture / รูป สำหรับ visualization 3D

3.3 Two telemetry backends (critical 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

คำถาม	คำตอบสั้น
Twin ต้องมีบอร์ดไหม	ไม่เสมอ — Simulator = เส้นทางไม่มีบอร์ด
บอร์ดยังจำเป็นไหม	ใช่ — RF, analog, พลังงาน, ขาพินจริง
ทำไมห้ามผสม	กันข้อมูล uart/sim ปะปนในกราฟเดียวกัน

รายละเอียด lifecycle จะฝึกใน M02/M04 — ใน M01 จำไว้ว่า Twin Environment มีอย่างน้อยสองโหมดเข้าสู่โฮสต์

4. Signals, Sensors, Behavior, and Data Pipeline

Twin จำลองได้หลาย ระดับความละเอียด — เลือกให้เหมาะกับคำถามที่ต้องการตอบ

4.1 Simulation levels

ระดับ	ตัวอย่าง	ใช้ตอบคำถามอะไร
I/O / pin logic	สวิตช์เสมือน, LED เสมือน	ตรรกะควบคุมพื้นฐาน
Sensor values	IMU, temp, pressure	อ่านค่า → filter → ตัดสินใจ
Behavior	เมื่อกดปุ่มแล้วเปลี่ยนโหมด	ตอบสนองต่อเหตุการณ์
Connectivity	MQTT pub/sub, lossy link	รูปแบบข้อความ + ความทนทาน
Presentation	กราฟ / 3D / dashboard	ผู้ใช้เห็นผลถูกต้องไหม

4.2 Data pipeline (one page)

[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 (M05)

ชุดข้อมูลที่ควรแยกในหัว (จะลงลึก M05):

ชนิด	ความหมาย
Telemetry	ค่าวัดที่ไหลเป็นคาบ (อุณหภูมิ, accel, …)
State	สถานะระบบ (connected, mode, streaming)
Event	เหตุการณ์จุดเดียว (threshold crossed, button, alert)

สิ่งที่ต้องชัดตอนออกแบบเทส:

อินพุตมาจาก สคริปต์ / Simulator / ผู้ใช้ Twin หรือจาก โลกจริง
เฟิร์มแวร์ยัง “คิดว่า” กำลังอ่านฮาร์ดแวร์ผ่านชั้นที่ออกแบบไว้
ผลลัพธ์ต้องสังเกตได้ใน console + visualization อย่างน้อยหนึ่งอย่าง

5. Firmware Reality vs Twin Environment

บนบอร์ดจริง	บน Twin / Simulator
Driver ↔ ซิลิคอน / วิทยุจริง	พอร์ตจำลอง ↔ Virtual Device / sim inject
Timing จากคริสตัล + RTOS จริง	Timing จำลอง — latency โฮสต์มีผล
ดีบักด้วย probe / UART	ดีบักผ่าน VS Code + log / panels ของโฮสต์
RF / analog / พลังงานวัดได้	มัก จำลองไม่ได้ครบ — ต้องยืนยันบนบอร์ด

5.1 Decision guide (preview of lab table)

สถานการณ์	Twin/Sim พอไหม	ต้องบอร์ดจริงไหม
Logic สลับโหมดจากปุ่ม	มักพอ	ไม่จำเป็นระยะแรก
รูปแบบ JSON / MQTT topic	พอ (ดีมาก)	ยืนยันรอบสุดท้ายถ้าใช้ Wi‑Fi จริง
อ่าน IMU แล้วคำนวณบนโค้ด	พอสำหรับ logic	ยืนยัน noise/bias จริงบนบอร์ด
Wi‑Fi ระยะ / BLE ห้องจริง	ไม่แทน	ต้อง
ตรวจ pin map / บัดกรีผิด	ไม่แทน	ต้อง

5.2 Recommended workflow

พัฒนาและเคสขอบบน Twin / Simulator
ใช้ชุดเทส (topic, payload, scenario) ชุดเดียวกันให้มากที่สุด
ยืนยันรอบสุดท้ายบน ฮาร์ดแวร์จริง โดยเฉพาะ analog, RF, พลังงาน
เก็บหลักฐานทั้งสองโลกเมื่อส่ง Capstone (M06)

6. Course 2 Map — Where M01 Fits

Module	คุณจะทำอะไรต่อจากแผนที่นี้
M01 (ตอนนี้)	ชี้ชั้น Twin + ตัดสินใจเทส
M02	ติดตั้ง Bitstream Studio, ผูก workspace, Run/Debug ดูผล
M03	สร้าง Virtual Device + behavior + event script
M04	Co-sim เฟิร์มแวร์ ↔ Twin วัด timing
M05	Telemetry pipeline + MQTT + lossy network
M06	E2E mini-project + เอกสารส่งมอบ

Next Steps

ทำแล็บแผนที่: แล็บ
เก็บแผ่นสูตร: twin-architecture-map.md
เมื่อพร้อม ไปต่อ M02 — VS Code for Twin Development

References and Further Reading

Bitstream Studio
TESAIoT Developer Hub
TESAIoT_Hackathon
ternion-3d-assets-free — assets/
Course 2 TOC · Course 1 TOC
Digital twin (overview)
MQTT Essentials — ทบทวนชั้น cloud ที่จะแตะใน M05
PSOC™ Edge E84 — physical device อ้างอิง

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

คำถามสั้นสามข้อใน quiz.yaml ผูกกับเป้าหมายของบทเรียนนี้ข้อละหนึ่งคำถาม ลองตอบเองก่อน แล้วค่อยเทียบกับเฉลยและคำอธิบายในไฟล์

แล็บ

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

Lab · Cheatsheet · ← Table of Contents · M02 →

คำถามทบทวน

ลองตอบเองก่อน แล้วค่อยเปิดดูเฉลย

“แบบจำลองซอฟต์แวร์ของอุปกรณ์หนึ่งตัว ทั้งพิน เซ็นเซอร์ สถานะ และพฤติกรรมตอบสนอง” คือข้อใด (เป้าหมายข้อ 1)
1. Host / Twin UI
2. Virtual Device
3. Digital Twin Platform
4. Physical Device
ดูเฉลย

คำตอบ: B. Virtual Device

ตารางในหัวข้อ 2: Digital Twin Platform คือสภาพแวดล้อมที่รวม Virtual Device กับการสื่อสาร visualization สคริปต์ และ cloud จำลอง
ทำไม Bitstream Studio ให้ใช้ Bitstream หรือ Simulator ทีละเส้น (เป้าหมายข้อ 2)
1. เพราะ Simulator ต้องต่อบอร์ดด้วยเสมอ
2. เพราะ UART เร็วเกินกว่า UI จะแสดงได้
3. เพื่อประหยัดพลังงานของบอร์ด
4. เพื่อกันข้อมูล uart กับ sim ปะปนในกราฟเดียวกัน
ดูเฉลย

คำตอบ: D. เพื่อกันข้อมูล uart กับ sim ปะปนในกราฟเดียวกัน

หัวข้อ 3.3 Two telemetry backends: ห้ามผสมเพื่อกันข้อมูล uart/sim ปะปนกัน
สถานการณ์ใดที่บทเรียนระบุว่า Twin “ไม่แทน” และต้องใช้บอร์ดจริง (เป้าหมายข้อ 3)
1. การคำนวณบนค่า IMU ในโค้ด
2. ระยะ Wi-Fi หรือ BLE ในห้องจริง
3. logic สลับโหมดจากปุ่ม
4. รูปแบบ JSON และ MQTT topic
ดูเฉลย

คำตอบ: B. ระยะ Wi-Fi หรือ BLE ในห้องจริง

ตาราง Decision guide ในหัวข้อ 5.1: RF จริงและ pin map ต้องยืนยันบนบอร์ด

อ้างอิงบทเรียนนี้

ถ้านำบทเรียนนี้ไปสอน ทำสไลด์ หรือทำเอกสารต่อ ให้อ้างอิงด้วยข้อความนี้ ถ้าดัดแปลงเนื้อหา ให้เติม (ดัดแปลง)ต่อท้ายชื่อบทเรียน

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

ข้อความอ้างอิงภาษาอังกฤษ: "Virtual Devices, Digital Twins and Real Firmware" from TESA Open Knowledge by the Thai Embedded Systems Association (TESA), https://github.com/tesaiot/tesa-qualification-program, licensed under CC BY-NC 4.0

ลิงก์บทเรียน: https://tesaiot.github.io/tesa-qualification-program/courses/digital-twin/m01-twin-architecture/l01-twin-architecture/

บทเรียนนี้ดัดแปลงจากต้นฉบับด้านล่าง เมื่ออ้างอิงให้คงเครดิตต้นฉบับไว้ด้วย
https://github.com/drsanti/TESAIoT-Courses/blob/287c21814ba8c75f693136616dcd270349a15966/C2/M01/README.md · Original content by Asst. Prof. Dr. Santi Nuratch (ผศ.ดร.สันติ นุราช), KMUTT. Course 2 (C2/) of drsanti/TESAIoT-Courses. TESA funded the work and holds the rights; published here under CC BY-NC 4.0. The upstream repository carries no licence file. Text kept faithful; structure, front matter, quizzes and notes added by TESA Open Knowledge.

วิธีอ้างอิง TESA ฉบับเต็ม

เนื้อหาเผยแพร่ภายใต้ CC BY-NC 4.0 นำไปใช้ต่อในงานที่ไม่ใช่เพื่อการค้าได้ โปรดอ้างอิงสมาคมสมองกลฝังตัวไทย (TESA) ทุกครั้ง · วิธีอ้างอิง TESA