บทเรียน 4.1 — Co-simulation: พิสูจน์ I/O วัด latency และแยกปัญหา

เป้าหมาย

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

1. พิสูจน์เส้นทาง input (Twin → เฟิร์มแวร์) และ output (เฟิร์มแวร์ → Twin) ด้วยหลักฐานที่ตรวจตามรอยได้
2. วัด latency คร่าว ๆ ซ้ำสามครั้ง และระบุแหล่งหน่วงที่น่าจะเป็น
3. ไล่แยกปัญหาฝั่งเฟิร์มแวร์กับฝั่งโฮสต์ทีละชั้น โดยเปลี่ยนตัวแปรครั้งละอย่าง

ก่อนเริ่ม

• ผ่าน บทเรียน 3.2 — แล็บ M03 มาแล้ว — มี Virtual Device + event script พร้อมกระตุ้นซ้ำ
• ต้องใช้บอร์ดจริง (TESAIoT PSoC Edge DevKit) หรือโหมด Simulator ของ Bitstream Studio

Key phrase: Co-simulation = เฟิร์มแวร์คิดและตอบ ในเวลาเดียวกับที่ Twin กระตุ้นและแสดงผล — ไม่ใช่แค่เปิดกราฟดูค่า

ดูของจริงก่อน — Co-simulation คืออะไร (และไม่ใช่อะไร)

แนวคิด — สองเส้นทางแล็บที่ใช้ได้จริง

Path A:  [Simulator firmware] ──WS──► [Bridge] ──► [Bitstream Studio]
Path B:  [MCU firmware] ──UART──► [Bridge] ──► [Bitstream Studio]

ทั้งสอง path นับเป็น co-sim กับโฮสต์ Twin ได้ — ต่างกันที่แหล่งอินพุตฮาร์ดแวร์

แนวคิด — สามชั้นที่สังเกตสตรีมเดียวกันได้

ถ้าทั้งสามชั้น (หรืออย่างน้อย Studio + web-app) เห็นการเปลี่ยนแปลงสอดคล้องกันหลังกระตุ้น — คุณมีหลักฐาน co-sim ที่แข็งกว่า "แคปกราฟแผงเดียว"

แนวคิด — Bring-up: เซสชันเสถียรก่อนเสมอ

1. เปิด Bitstream Studio จาก workspace ที่ผูกแล้ว (โมดูล 2)
2. เลือก backend: Simulator หรือ Bitstream (ไม่ผสม)
3. Link / Connect จนสถานะปกติ
4. เห็นสตรีมเซ็นเซอร์หรือ log อย่างน้อยหนึ่งช่อง
5. (Path B) ยืนยัน HEX/VSIX เวอร์ชันจับคู่

ผ่านเมื่อ: เซสชันนิ่ง ≥ 30–60 วินาที โดยไม่หลุด Link เอง

ตัวอย่างสมบูรณ์ — เส้นทางที่ต้องพิสูจน์ให้ชัด

[Stimulus]  event script / UI / scene change / tilt board
        ▼
[Sensor or pin value]     ← Virtual Device or real sensor
        ▼
[Firmware read path]      ← task / driver / SENSOR_CFG
        ▼
[Firmware decision]       ← behavior WHEN/THEN
        ▼
[Firmware write path]     ← LED / flag / publish / log
        ▼
[Twin / Studio / web-app observe]

แนวคิด — หลักฐานของเส้นทาง Input และ Output

Input path (Twin → Firmware): กระตุ้นจากสคริปต์/UI → ค่าเข้าเฟิร์มแวร์ (UART log/ตัวแปร) → ค่าสอดคล้องชนิดเซ็นเซอร์

Output path (Firmware → Twin):

เกณฑ์สำเร็จ: ค่าที่กระตุ้นจาก Twin ไปถึง พฤติกรรมเฟิร์มแวร์ และคำสั่งจากเฟิร์มแวร์ ทำให้ สถานะบนโฮสต์เปลี่ยนตามที่คาด

แนวคิด — ทำไมต้องมี web-app ภายนอกเป็นพยาน

แผงใน Bitstream Studio อาจ "ดูถูก" เพราะกำลังทดสอบโฮสต์ตัวเดียวกันที่ decode สตรีมอยู่แล้ว หน้า HTML ใน TESAIoT_Hackathon/web-app/ เป็น client อิสระ — ถ้ามันอัปเดตตามการเอียงบอร์ดหรือ scene Motion แสดงว่า:

• bridge / provider เปิดอยู่
• sensor id และ fields ถูก publish
• ท่อข้อมูลไม่พังเฉพาะ UI ภายใน extension

ตัวอย่างหลักของบทนี้: ex05_bmi270_orientation.html — artificial horizon + Euler angles จาก BMI270

ตัวอย่างสมบูรณ์ — บทเรียนจาก ex05: mask ต้องตรงสัญญา

หน้า ex05 เขียนไว้ชัดว่า accel/gyro อย่างเดียวไม่พอ ต้องเปิดใน sensor settings ให้ BMI270 publish อย่างน้อยหนึ่งชุดนี้:

ถ้า mask มีแต่ accel/gyro: horizon จะค้างที่ waiting for orientation fields… — นี่คือตัวอย่าง fault isolation ที่ดี: สตรีมมี แต่ consumer เงียบเพราะ fields ไม่ตรงสัญญา ไม่ใช่เพราะ "web-app พัง"

ตัวอย่างสมบูรณ์ — จับคู่ ex05 กับข้อพิสูจน์ของ M04

แนวคิด — วัด latency และหาแหล่งหน่วง

ทำซ้ำ 3 ครั้งแล้วจดช่วงค่า (min–max) — ลำดับที่มักเห็น: log เร็วสุด → Studio ใกล้เคียง → web-app ช้ากว่าเล็กน้อย

แหล่งหน่วงที่พบบ่อย: คาบ vTaskDelay ของ RTOS task · sensor publish interval (Lab Quiet ช้ากว่า Motion) · bridge/WS/UI refresh

ตัวอย่างสมบูรณ์ — ไล่แยกปัญหาทีละชั้น

1. Extension / backend up?
2. Correct source (sim XOR uart)?
3. Stream present at all?
4. Stimulus actually applied?
5. Firmware log shows read?
6. Firmware log shows write/decision?
7. Studio UI shows change?
8. web-app (ex05) shows change?

Key phrase: แก้ทีละชั้น — อย่าเปลี่ยนเฟิร์มแวร์และโหมด Studio พร้อมกันในรอบดีบักเดียว

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

แล็บ: I/O ครบวงจรแบบ co-simulation

• Bring-up เซสชันให้เสถียรก่อน (≥ 30–60 วินาที)
• พิสูจน์เส้นทาง input และ output พร้อมหลักฐาน
• เปิด web-app/ex05 เป็นพยานชั้นที่สอง (ถ้าเป็นไปได้)
• วัด latency 3 รอบ และไล่แยกปัญหาถ้ามีจุดใดไม่สอดคล้อง

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

1. "Co-simulation" ในบทเรียนนี้หมายถึงข้อใด
2. เมื่อวัด latency ลำดับความเร็วที่มักเห็นคือข้อใด
3. เฟิร์มแวร์ log ถูกต้องแต่ UI ไม่ขยับ น่าสงสัยฝั่งใด

ไปต่อ

• Co-simulation คือเฟิร์มแวร์และ Twin ทำงานพร้อมกัน ไม่ใช่แค่เปิดกราฟดูค่า
• พิสูจน์ input และ output ด้วยหลักฐานตามรอยได้ — ใช้ web-app ภายนอกเป็นพยานชั้นที่สอง
• วัด latency ซ้ำสามครั้ง และแก้ปัญหาทีละชั้นเสมอ
• พร้อมแล้วสำหรับ โมดูล 5 — ท่อ telemetry, MQTT บน Twin และ fault injection

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

แหล่งที่มา

"บทเรียน 4.1 — Co-simulation: พิสูจน์ I/O วัด latency และแยกปัญหา" จาก 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

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