Skip to content
TESA Open Knowledge

Virtual Devices, Digital Twins and Real Firmware

Companion videos

Watch on YouTube (opens in a new tab)

Videos by Thai Embedded Systems Association (TESA) · The whole series in the playlist AIoT Foundation

Course 2 · Module 1 Suggested time: about 2 hours (concepts + a diagram + opening the host to see the data pipeline) Format: a conceptual lesson — building a full Virtual Device is not yet required (hands-on work starts in M02 / M03)

Lab · Cheatsheet · ← Table of Contents · M02 →

Objectives (Learning Outcomes)

Section titled “Objectives (Learning Outcomes)”

By the end of this lesson you should be able to:

  1. Explain the Virtual Device and Digital Twin concepts in IoT / Firmware work
  2. Explain the TESA Digital Twin Platform architecture as layers you can put into practice in the lab
  3. Explain simulating signals, sensors, device behaviour, and the Data Pipeline
  4. Identify the relationship between real Firmware and the Twin Environment — when to use a board / when to use the Simulator / when you must confirm on hardware

This module is the mental map for Course 2. Once you understand the Twin’s architecture, installing the VS Code host (M02) and building a Virtual Device (M03) will have a clear frame.

The approach: “state the concept, then point at the real tool” The course documentation talks about the Twin platform’s engines at the architecture level. In the lab, the main host is Bitstream Studio + the TESAIoT_Hackathon pack — this lesson pairs the concept with what you actually open in the lab.

Read alongside this chapter

Section titled “Read alongside this chapter”
Document Use when
Bitstream Studio (Marketplace) The VS Code host — telemetry, Sensor Studio, the Simulator, MQTT, a 3D preview
TESAIoT Developer Hub Firmware / API examples that will flow into the Twin
TESAIoT_Hackathon HEX, VSIX, the Flasher, web-app/ dashboards
ternion-3d-assets-free 3D models (GLB), textures, cubemaps, images for the Twin / Sensor Studio
Course 1 TOC The SDK / sensors / MQTT / BLE fundamentals
Course 1 M05 — Sensor prep The data source that will feed the pipeline
Course 1 M06 — MQTT The cloud layer the Twin will simulate/test
Bluetooth / local path (C1 M07) The local option when not using Wi‑Fi
Digital Twin — Wikipedia overview A general definition outside the course (further reading)

1. Why Digital Twin for Firmware Development

Section titled “1. Why Digital Twin for Firmware Development”

IoT / Edge AI firmware development today is no longer just “blink an LED” — a system usually has:

  • Several sensors + filtering/data windows
  • Several RTOS tasks
  • Connectivity (Wi‑Fi / MQTT / BLE)
  • A host watching values in real time, and sometimes the cloud

If you test every case on real hardware alone, you run into high cost, slow turnaround, and risk to the hardware.

Digital Twin in this course means building a digital stand-in for the device in a virtual environment, so you can develop, test, analyse and demonstrate it without relying on a real board the whole time.

1.1 What Twin Helps You Do

Section titled “1.1 What Twin Helps You Do”
Benefit Meaning in the lab
Simulating hardware Reading sensor values/status without wiring up every real pin
Repeatable logic testing A script can shake the IMU / press a switch / cut the network, repeatably
Reducing board risk Test edge cases on the Twin before flashing the real thing
Seeing results immediately A graph / panel / 3D view / host dashboard
Preparing before the cloud Checking the telemetry format / topic before going to a real broker

Key phrase The Twin does not replace the board 100% — it is a bridge between firmware theory and repeatable testing.

1.2 Prerequisites from Course 1

Section titled “1.2 Prerequisites from Course 1”

Course 2 assumes you already know (or can review):

From Course 1 How it’s used in Course 2
The SDK layers / chip domains Knowing where the app code lives
Sensors + windows The data that will feed the Twin / dashboard
MQTT / BLE The channels the Twin and the cloud will test
Capstone patterns The task structure + indication + connectivity

2. Virtual Device vs Digital Twin

Section titled “2. Virtual Device vs Digital Twin”
Term Meaning in this course
Physical Device The real board + sensors (such as a PSoC Edge kit)
Virtual Device A software model of one device — pins, sensors, state, response behaviour
Digital Twin (Platform) An environment combining the Virtual Device + communication + visualization + event scripts + (often) a simulated MQTT/cloud
Firmware Logic The product’s logic code, which should run against both the Twin and hardware, once the I/O layer is properly separated
Host / Twin UI The VS Code extension and host app you use to see the result — in this course, mainly Bitstream Studio 
Physical Device  ≈  "the real thing on the desk"
Virtual Device   ≈  "a model of one device, in software"
Digital Twin     ≈  "a whole simulated factory" (model + comms + screen + scripts + cloud sim)

A good code-design goal:

  • Separate application logic from the raw hardware detail enough
  • Be able to switch targets (Simulator / board / MQTT host) without rewriting the whole app

3. TESA Digital Twin Platform Architecture

Section titled “3. TESA Digital Twin Platform Architecture”

The course explains the platform as a set of engines working around a central core — learners don’t need to memorise every sub-product’s name, but should be able to point out where each role sits during the lab.

3.1 Conceptual engines (curriculum map)

Section titled “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
Layer (concept) Role What is usually opened in this lab
Digital Twin Engine Manages the Virtual Device’s state, simulated time, coordinates events The sensor/mode state in Studio · the Simulator stream
Communication Engine The data channel between firmware ↔ host ↔ cloud The UART/bridge, the MQTT broker in Studio, the BLE host as needed
Graphics / Visualization Graphs, panels, 3D, orientation Sensor Telemetry · Sensor Studio · a 3D rotation preview
User Interaction Input from the learner (buttons, scripts, toolbar modes) Switching the Bitstream/Simulator backend · driving the scene · publishing commands
Scripting & Events Repeatable event simulation An event script / behaviour (detail in M03) · fault injection (M05)
AI Connectivity (extra) Sending data off for analysis / receiving a result back The path prepared in Course 1 M05 — not required in M01
Physics (extra) Simulating motion/force when a model needs it Used when the project has a mechanism — not every lab

Honest mapping Each extension version’s UI may differ — remember the layer’s role, not every screen’s exact button position.

3.2 Concrete lab stack (what you install)

Section titled “3.2 Concrete lab stack (what you install)”
Piece Role in Course 2
Bitstream Studio The main VS Code host — Twin / telemetry / MQTT / 3D
Bitstream Simulator (a companion when using Simulator mode) A virtual MCU that injects telemetry with no COM port needed
A board + HEX from Hackathon The physical path — confirming against the real thing
The Hackathon web-app/ An external dashboard watching the telemetry / MQTT pipe
The Developer Hub The upstream firmware examples
ternion-3d-assets-free GLB / textures / images for 3D visualization

3.3 Two telemetry backends (critical mental model)

Section titled “3.3 Two telemetry backends (critical mental model)”

An important concept in Bitstream Studio: Bitstream (UART/board) and Simulator are live paths that are used one at a time — never mixed in the UI.

Toolbar source = Bitstream  →  COM open  →  samples origin: uart
Toolbar source = Simulator →  COM closed →  samples origin: sim
Question Short answer
Does the Twin need a board? Not always — the Simulator is a board-free path
Is a board still necessary? Yes — for RF, analogue, power, and real pins
Why must they never mix? To prevent uart/sim data from mixing into the same graph

The lifecycle detail is practised in M02/M04 — in M01, just remember that the Twin Environment has at least two ways into the host.

4. Signals, Sensors, Behavior, and Data Pipeline

Section titled “4. Signals, Sensors, Behavior, and Data Pipeline”

The Twin can simulate at several levels of detail — choose the one that fits the question you want answered.

4.1 Simulation levels

Section titled “4.1 Simulation levels”
Level Example Answers what question
I/O / pin logic A virtual switch, a virtual LED Basic control logic
Sensor values IMU, temperature, pressure Reading a value → filtering → deciding
Behavior A mode change when a button is pressed Responding to an event
Connectivity MQTT pub/sub, a lossy link The message format + robustness
Presentation A graph / 3D view / dashboard Does the user see the correct result?

4.2 Data pipeline (one page)

Section titled “4.2 Data pipeline (one page)”
[Source]
  board sensors  or  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)

Data types worth telling apart mentally (detail in M05):

Type Meaning
Telemetry Periodic measured values (temperature, accel, …)
State System state (connected, mode, streaming)
Event A single-point occurrence (a threshold crossed, a button, an alert)

What must be clear when designing a test:

  1. Whether the input comes from a script / the Simulator / a Twin user, or from the real world
  2. The firmware still “thinks” it is reading hardware through the layer it was designed with
  3. The result must be observable in the console + visualization, in at least one form

5. Firmware Reality vs Twin Environment

Section titled “5. Firmware Reality vs Twin Environment”
On a real board On the Twin / Simulator
A driver ↔ real silicon / a real radio A simulated port ↔ the Virtual Device / a sim injection
Timing from a crystal + a real RTOS Simulated timing — the host’s latency has an effect
Debugging with a probe / UART Debugging through VS Code + the host’s logs / panels
RF / analogue / power can be measured Usually cannot be fully simulated — must be confirmed on the board

5.1 Decision guide (preview of lab table)

Section titled “5.1 Decision guide (preview of lab table)”
Scenario Is the Twin/Sim enough? Does it need a real board?
Mode-switching logic from a button Usually enough Not necessary at first
A JSON format / an MQTT topic Enough (very good for this) Confirm in a final round if using real Wi‑Fi
Reading the IMU and computing in code Enough for the logic Confirm real noise/bias on the board
Wi‑Fi range / BLE in a real room Cannot substitute for this Required
Checking a pin map / a soldering mistake Cannot substitute for this Required
Section titled “5.2 Recommended workflow”
  1. Develop and test edge cases on the Twin / Simulator
  2. Reuse as much of the same test set (topics, payloads, scenarios) as possible
  3. Confirm in a final round on real hardware, especially analogue, RF, and power
  4. Keep evidence from both worlds when submitting the Capstone (M06)

6. Course 2 Map — Where M01 Fits

Section titled “6. Course 2 Map — Where M01 Fits”
Module What you will do next, from this map
M01 (now) Point out the Twin’s layers + decide which tests fit
M02 Install Bitstream Studio, bind the workspace, Run/Debug and see the result
M03 Build a Virtual Device + behaviour + an event script
M04 Co-simulate firmware ↔ Twin, measuring timing
M05 The telemetry pipeline + MQTT + a lossy network
M06 An E2E mini-project + delivery documentation

Next Steps

Section titled “Next Steps”
  1. Do the mapping lab: Lab
  2. Keep the summary sheet: twin-architecture-map.md
  3. When ready, continue to M02 — VS Code for Twin Development

References and Further Reading

Section titled “References and Further Reading”
  1. Bitstream Studio
  2. TESAIoT Developer Hub
  3. TESAIoT_Hackathon
  4. ternion-3d-assets-free — assets/
  5. Course 2 TOC · Course 1 TOC
  6. Digital twin (overview)
  7. MQTT Essentials — reviewing the cloud layer touched in M05
  8. PSOC™ Edge E84 — the reference physical device

Check your understanding

Section titled “Check your understanding”

Three short questions in quiz.yaml, one per objective of this lesson. Try answering them yourself first, then compare with the answer key and explanations in the file.

Lab

Section titled “Lab”

Continue hands-on at Lab: mapping the Twin architecture

Lab · Cheatsheet · ← Table of Contents · M02 →

Review questions

Answer on your own first, then open the answer.

  1. “แบบจำลองซอฟต์แวร์ของอุปกรณ์หนึ่งตัว ทั้งพิน เซ็นเซอร์ สถานะ และพฤติกรรมตอบสนอง” คือข้อใด (Objective 1)

    1. Host / Twin UI
    2. Virtual Device
    3. Digital Twin Platform
    4. Physical Device
    Show answer

    Answer: B. Virtual Device

    ตารางในหัวข้อ 2: Digital Twin Platform คือสภาพแวดล้อมที่รวม Virtual Device กับการสื่อสาร visualization สคริปต์ และ cloud จำลอง

  2. ทำไม Bitstream Studio ให้ใช้ Bitstream หรือ Simulator ทีละเส้น (Objective 2)

    1. เพราะ Simulator ต้องต่อบอร์ดด้วยเสมอ
    2. เพราะ UART เร็วเกินกว่า UI จะแสดงได้
    3. เพื่อประหยัดพลังงานของบอร์ด
    4. เพื่อกันข้อมูล uart กับ sim ปะปนในกราฟเดียวกัน
    Show answer

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

    หัวข้อ 3.3 Two telemetry backends: ห้ามผสมเพื่อกันข้อมูล uart/sim ปะปนกัน

  3. สถานการณ์ใดที่บทเรียนระบุว่า Twin “ไม่แทน” และต้องใช้บอร์ดจริง (Objective 3)

    1. การคำนวณบนค่า IMU ในโค้ด
    2. ระยะ Wi-Fi หรือ BLE ในห้องจริง
    3. logic สลับโหมดจากปุ่ม
    4. รูปแบบ JSON และ MQTT topic
    Show answer

    Answer: B. ระยะ Wi-Fi หรือ BLE ในห้องจริง

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

Cite this lesson

If you teach from this lesson or reuse it in slides or documents, credit it with the text below. If you changed it, add (adapted) after the title.

"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

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

Lesson link: https://tesaiot.github.io/tesa-qualification-program/en/courses/digital-twin/m01-twin-architecture/l01-twin-architecture/

This lesson adapts the source below; keep its credit too.
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.

Full guide: how to cite TESA

TESA Open Knowledge · © 2026 สมาคมสมองกลฝังตัวไทย (TESA) · CC BY-NC 4.0

Content is licensed CC BY-NC 4.0. Reuse it non-commercially and credit the Thai Embedded Systems Association (TESA) every time. · How to cite TESA