Skip to content
TESA Open Knowledge

Virtual Devices, Behaviours, Event Scripts and 3D Models for the Twin

Companion videos

Watch on YouTube (opens in a new tab)

Videos by Thai Embedded Systems Association (TESA) · Asst. Prof. Dr. Santi Nuratch, Department of Control Systems and Instrumentation Engineering, Faculty of Engineering, King Mongkut's University of Technology Thonburi (KMUTT) · The whole series in the playlist AIoT Foundation

Course 2 · Module 3 Suggested time: about 4–5 hours (Virtual Device + behavior/script + a Blender for Twin 3D introduction) Format: a hands-on lesson — designing a Virtual Device + Blender basics (Modeling / Texturing / Animation) for visualization on the Twin

Lab · Device checklist · Blender cheatsheet · ← Table of Contents · ← M02 · M04 →

Note: the tables in this lesson reference scene buttons in TESAIoT_Hackathon’s ble-flet, but that repo’s README (commit f5f09a6) states ble-flet/ is not published. Use the panels in Bitstream Studio instead (checked on 2026-09-26)

Objectives (Learning Outcomes)

Section titled “Objectives (Learning Outcomes)”

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

  1. Build and configure a Virtual Device Model that reflects the course’s target board
  2. Simulate key sensors, such as IMU, Temperature, Pressure, Switches
  3. Define Behavior Simulation so the input→state path is checkable
  4. Write a repeatable Event Simulation Script for regression / demonstration
  5. Explain Blender’s role in building a 3D model for the Twin: Modeling, Texturing, Animation, and the export glTF/GLB path
  6. Use online documentation (the Blender Manual / Fundamentals / the Thai-language tutorial) and ternion-3d-assets-free to keep learning on your own

This module builds on M02, where the host is already ready — now you will design what the Twin simulates (data + 3D shape), before bringing firmware into deeper co-sim in M04.

The approach: “model on paper + run on real tools + prepare 3D” The Virtual Device Configuration describes behaviour/sensors. Blender prepares the visual shell the Twin / Sensor Studio displays — Course 3 goes deep into industrial design work; here we focus on enough skill for Course 2.

Read alongside this chapter

Section titled “Read alongside this chapter”
Document Use when
M01 — Twin Architecture Which layer of the platform the Virtual Device sits in
M02 — VS Code Twin Opening the Simulator / Bitstream Studio before this lab
Course 1 M05 — Sensor prep Sensor types and what their values mean
Bitstream Studio The host to see the result after setting up the model/scene
TESAIoT_Hackathon ble-flet scene presets · web-app/
ternion-3d-assets-free GLB models / textures / images for the Twin
Blender Manual 4.5 LTS The official manual for Modeling / Materials / Animation
Blender Fundamentals 4.5 LTS An official video course from Blender Studio (English)
INC111-2021 Blender playlist (Thai) A Thai-language tutorial on YouTube — recommended for learners who want a Thai explanation
TESAIoT Developer Hub Sensor examples on the firmware side
A conceptual model example A JSON skeleton for your deliverable
Blender cheatsheet Quick links for Modeling / Texturing / Animation / glTF

1. What Is a Virtual Device Model

Section titled “1. What Is a Virtual Device Model”

A Virtual Device Model is a software description of one device in the Twin world. At minimum, it should state:

Part Question it must answer
Identity A fixed device name / id to reference in a report
Sensors What exists · units · default value · the accepted range
Actuators / outputs LEDs, flags, logs — things whose result can be observed
Noise / dynamics (if any) Are values jumpy, or is simulated noise present?
Behaviors When an input/command occurs, how does the state change?
Events / scripts Timed scenarios that can be run again

The model does not need to simulate every block in the silicon — it must be enough to test the firmware’s logic per the lab’s task.

Too rough More detail than needed
Tests don’t reflect real behaviour Wasted setup time that adds no learning

Key phrase A Virtual Device is an agreement between your test script and the Twin — not the whole datasheet.

1.1 Conceptual model document

Section titled “1.1 Conceptual model document”

Keep the model as a document the team can reread — an example skeleton in sample-virtual-device.template.json:

{
  "deviceId": "tesa-edge-demo-01",
  "displayName": "TESA Edge Demo Device",
  "sensors": [
    { "id": "temp", "type": "temperature", "unit": "C", "default": 25.0, "min": -10.0, "max": 85.0 },
    { "id": "btn_user", "type": "switch", "default": 0 },
    { "id": "imu", "type": "imu", "axes": ["ax", "ay", "az"], "default": [0, 0, 1] }
  ],
  "actuators": [
    { "id": "led_status", "type": "led", "default": 0 }
  ],
  "behaviors": [
    { "when": "command.led == on", "then": "actuators.led_status = 1" },
    { "when": "sensors.temp > 40", "then": "emit event threshold_exceeded" }
  ]
}

This file is a conceptual template for learning — the real tool’s fields may be named differently; map it to the Simulator / scene / SENSOR_CFG per the kit you use.

1.2 How the lab stack realizes the model

Section titled “1.2 How the lab stack realizes the model”
Part of the model What is usually used to run it for real, in this course
The sensor list + rates SENSOR_CFG / scene presets (Motion, Lab Quiet, Environment, …)
Continuous IMU / env values The Bitstream Simulator stream, or a real board
Identity The device name / the MAC topic / deviceId in the report
Behavior (command → output) A host command / an MQTT actuator / an LED on the board or UI
A timed event script A timeline in the checklist + switching scenes / manually triggering / a script, depending on the tool you have

2. Modeling Sensors

Section titled “2. Modeling Sensors”

2.1 Sensor families in this course

Section titled “2.1 Sensor families in this course”
Type Value usually simulated Good for testing
IMU (such as BMI270) accel / gyro (and fusion, depending on mode) gesture, activity, orientation
Temperature / Humidity (such as SHT40) A continuous scalar threshold, a calibration path
Pressure (such as DPS368) A continuous scalar an environmental monitor
Magnetometer (such as BMM350) Field axes heading / fusion labs
Switches / buttons 0/1 or an edge UI logic, debounce

Recommended learning order:

  1. A switch + temperature (the result is easy to observe)
  2. Add the IMU once the data pipe is ready
  3. Combine env sensors into a monitor set

Review what the values mean: Course 1 M05

2.2 Rates and scenes (practical knobs)

Section titled “2.2 Rates and scenes (practical knobs)”

Instead of exposing every wire-level field right away, a lab host usually has scene presets at the use-case level:

Scene (an example in the lab pack) Approximate meaning
Motion The IMU is denser · env is slower — suited to posture / motion
Realtime A higher rate, for watching brief detail
Lab Quiet ~1 Hz for everything — good for demos / saving resources
Environment Emphasises SHT/DPS · the IMU is off or reduced

In Bitstream / BLE labs, applying a scene usually means a SENSOR_CFG set (+ a BMI270 / fusion mode, depending on the tool) — learners should focus on which profile the model needs, not memorise every millisecond on day one.

2.3 Defaults, ranges, and honesty

Section titled “2.3 Defaults, ranges, and honesty”

When filling in a model, state:

Field Why it matters
default The value when a script starts / before triggering
min / max Prevents an unintentionally unrealistic test
The unit Prevents confusing °C / Pa / g
“sim vs real” A value from the Simulator is sine/synthetic — not real board noise

3. Behavior Simulation

Section titled “3. Behavior Simulation”

Behavior is the rule stating how the simulated device (or the firmware + host) responds once an input or command occurs.

3.1 Patterns worth practicing

Section titled “3.1 Patterns worth practicing”
Pattern Example Observe the result at
Command → actuator led=on → the status LED turns on The UI / the board / a log
Sensor → event temp > 40 → threshold_exceeded The event panel / MQTT / UART
Switch → mode Press a button → the publish mode changes The toolbar / the stream rate
Host write → device A command from Studio/MQTT The firmware responds

Write a behaviour that is testable on both input and output — if there is only “the value moves” without an agreement on what should happen, you cannot measure whether the logic is correct.

3.2 Keep behaviors small

Section titled “3.2 Keep behaviors small”

In M03, at least 1 path written as a clear sentence is required, for example:

WHEN user_button rising edge
THEN led_status = ON for 1 s AND log "btn"

Or:

WHEN temperature > 40 °C for 2 s
THEN emit event "temp_high"

Expand the number of behaviors in M04/M06, once co-sim and E2E are ready.

4. Event Simulation Scripts

Section titled “4. Event Simulation Scripts”

An Event Simulation Script builds a timed scenario, so regression and demonstration can be repeated.

4.1 Timeline example

Section titled “4.1 Timeline example”
t = 0–2 s   : idle (defaults)
t = 2–5 s   : temperature ramp +0.5 °C / step
t = 5.0 s   : press virtual switch ~200 ms
t = 6.0 s   : short IMU shake pulse
t = 7–10 s  : observe outputs / events
t = 10 s    : stop or loop

4.2 How to “run” a script in the lab

Section titled “4.2 How to “run” a script in the lab”

Choose at least one method, per the tools you have:

Method Use when
A manual timeline Follow the clock + notes — this passes M03’s bar
A scene switch Start Lab Quiet → switch to Motion at t=6 to trigger the IMU path
Host / app controls A scene button in ble-flet, or a Studio panel
A formal script file If that round’s Twin tooling supports a script file — attach a relative path in the checklist

What matters is the sequence of events + the expected result + evidence, not a specific scripting language.

4.3 Regression mindset

Section titled “4.3 Regression mindset”

Keep the script/timeline in your lab folder:

lab-notes/
  device-model.json      # from the template
  event-script-v1.md     # the timeline
  evidence/              # before/after screenshots

Once you edit the firmware in M04+, rerun the same script — if the result changes unintentionally, that’s a regression signal.

5. Blender for Twin Visualization

Section titled “5. Blender for Twin Visualization”

The Virtual Device in the previous section describes data and behaviour — this section prepares a 3D visual stand-in for the product/board, to display in the Digital Twin / Sensor Studio.

Blender is free, open-source 3D software that this course uses as the main path to glTF / GLB files, which the web host and Bitstream Studio support.

Work layer in M03 What you practise The Twin destination
Modeling Building the mesh shape of the case/board A shape in the 3D scene
Texturing UVs + a material / texture A surface that looks realistic on the host
Animation A brief keyframe / action Showing an open-close mechanism, or a motion demo
Export .glb Loaded into Studio / compared against ternion-3d-assets-free

Course 2 vs Course 3 Here you get enough foundation to use with the Twin. The Product Industrial Design (Blender & Twin) course goes deep into casing, industrial workflow, validation and prototyping — don’t wait for Course 3 if you just need a model to accompany telemetry in Course 2.

A quick-link sheet: blender-twin-cheatsheet.md

5.1 Getting Blender and the UI

Section titled “5.1 Getting Blender and the UI”
  1. Download from blender.org/download
  2. Read the interface overview: User Interface (Manual 4.5)
  3. The full manual: Blender 4.5 LTS Manual, or latest
  4. An official video path (English): Blender Fundamentals 4.5 LTS
  5. A Thai-language video path: INC111-2021 YouTube playlist

Modes you’ll use often when building a device model:

Mode Use when Read more
Object Mode Moving/rotating/scaling a whole piece, combining objects Scenes & Objects
Edit Mode Editing points, edges, faces (a mesh) Mesh introduction
Shading workspace Arranging material / texture nodes Materials
Animation editors Timeline, Dope Sheet, Graph Editor Animation intro

5.2 Modeling (building the shape)

Section titled “5.2 Modeling (building the shape)”

Modeling in Blender usually starts from a mesh primitive (cube, cylinder, plane…) and then enters Edit Mode to shape it — per Mesh Modeling introduction

Main skills worth knowing in Course 2

Section titled “Main skills worth knowing in Course 2”
Skill Why it matters for the Twin Documentation
Select / Extrude Building the case’s walls, thick edges Extrude
Loop Cut / Bevel Rounded edges, splitting a face for UVs Loop Cut · Bevel
Modifiers (Mirror, Solidify, Subdivision) Building symmetry/thickness without redoing it by hand Modifiers
Apply Scale / origin Preventing the model from distorting when put into the Twin or animated Transforms

A video workshop: Fundamentals — Modeling chapter

An approach for an Edge / DevKit device model

Section titled “An approach for an Edge / DevKit device model”
  1. Set the units to metres (or at least keep a consistent scale across the whole scene)
  2. Place the origin at a meaningful point (a corner of the board, the lid’s hinge axis, the point that sits on a desk)
  3. Separate parts that may move (a lid, buttons, LEDs) into their own objects if you’ll animate them
  4. Control the polygon count — the Twin’s webview doesn’t need film-level density
  5. Compare the style with the models in ternion-3d-assets-free /assets/models

Key phrase Good modeling for the Twin = readable shape + real scale + a clear origin + UVs ready — not detail for an advertising render.

Further study (Modeling):

5.3 Texturing (materials and surfaces)

Section titled “5.3 Texturing (materials and surfaces)”

Texturing, in the Twin context, means giving the model’s surface a colour / gloss / pattern that can be exported to glTF.

Main concepts

Section titled “Main concepts”
Concept Short meaning Documentation
Material A description of the surface on an object Materials introduction
Principled BSDF The standard PBR node that glTF understands well Principled BSDF
UV map 2D unwrap coordinates onto a texture UV editing · Unwrapping
Image texture An image file (albedo / roughness / …) Image Texture node
Texture Paint Painting a pattern directly on the model Texture Paint
Section titled “Recommended workflow for Course 2”
Mesh ready
  → Unwrap UV (Smart UV Project or by hand)
  → Principled BSDF
  → Base Color (± Roughness / Metallic maps)
  → Check in Material Preview / EEVEE
  → Export GLB (materials + UVs on)

Per the glTF 2.0 exporter:

  • The material that exports best is Metal/Rough PBR from Principled BSDF
  • Control the UV by connecting a UV Map (+ Mapping) into the Image Texture
  • Unlit/shadeless has its own path in the exporter’s manual, if you need a flat surface

Ready-to-use texture / cubemap sources in the Ternion system:

Further study (Texturing / shading):

5.4 Animation (motion)

Section titled “5.4 Animation (motion)”

Animation helps demonstrate product behaviour on the Twin, such as opening a lid, pressing a button, rotating an arm — matching the behavior/event script on the data side.

Main concepts

Section titled “Main concepts”
Concept Short meaning Documentation
Keyframe A point in time where a transform/property value is recorded Keyframes
Action A set of keyframes for an object Actions
Armature / bones A skeleton for complex parts Armatures
Shape keys Morphing a shape (a soft lid, rubber) Shape Keys
Constraints Restricting motion by a rule Constraints

Overview: Animation & Rigging introduction

What usually makes it to the Twin (through glTF)

Section titled “What usually makes it to the Twin (through glTF)”

Per the glTF 2.0 manual:

Generally supported Often doesn’t make it / gets overlooked
Keyframes of location / rotation / scale Some light / material animation
Skinning (armature) A complex driver that wasn’t baked
Shape key animation Blender-specific logic that isn’t exported

Tips for exporting animation:

  1. Make the action active, or arrange the NLA per what the exporter requires
  2. Test playing it back in Blender before exporting
  3. Turn on the Animation option in the glTF export window
  4. Check in Bitstream Studio / a viewer that the clip plays

Connecting to the Virtual Device The timeline in §4 (the event script) = a data event The timeline in Blender = a visual event In the Capstone (M06), try to make these two tell the same story.

Further study (Animation):

5.5 Export to Twin — glTF / GLB

Section titled “5.5 Export to Twin — glTF / GLB”

The recommended format for Bitstream Studio / the web Twin: glTF Binary (.glb), a single file combining mesh + materials + (if any) animation

Step Action Reference
1 Apply necessary transforms, check the origin The transforms manual
2 UV + Principled ready §5.3
3 Animation ready (if any) §5.4
4 File → Export → glTF 2.0 glTF 2.0 add-on (4.5)
5 Choose glTF Binary (.glb) · turn on Meshes / Materials / (Animations) The export window
6 Load it into Bitstream Studio, or compare it against the ternion-3d-assets-free pack M02’s Free Loader

The industry standard: Khronos glTF

Other formats (FBX/OBJ/STL) have their place for prototyping/3D printing — Course 3 goes deeper into that; in Course 2, focus on GLB for the Twin.

5.6 Suggested self-study path (Blender)

Section titled “5.6 Suggested self-study path (Blender)”

If you want to practise more on your own (~2–4 extra hours):

A Thai-language option (recommended if you want a Thai narration): watch the INC111-2021 playlist together with the exercise in Lab E — use the English Manual when you need the latest tool detail.

An official option (English):

  1. Fundamentals 4.5 — start
  2. Do the Modeling chapter until you have a simple part
  3. Read Principled BSDF + unwrap one piece
  4. Add a keyframe rotating/opening a lid for 2–3 seconds
  5. Export the .glb and try it in Studio
  6. Compare the quality against the models in assets/models

Blender’s UI changes by version — if a Thai clip uses an older version, treat the buttons/menus from the Manual 4.5+ as authoritative, and use the clip as a workflow concept.

6. Design Checklist Before You Build

Section titled “6. Design Checklist Before You Build”

Before starting the lab, be able to answer:

  1. Which logic of the firmware/product does this device test?
  2. What are the minimum sensors needed (at least 2 types)?
  3. Where do you observe the one behaviour path, on which screen?
  4. How long does the event script take, and who on the team can rerun it?
  5. (Recommended) will you use a 3D model from Blender, or from ternion-3d-assets-free?

A form to fill in: device-model-checklist.md · blender-twin-cheatsheet.md

Next Steps

Section titled “Next Steps”
  1. Do the Virtual Device lab: Lab
  2. Fill in the checklist + attach the model/timeline
  3. (Recommended) the Blender lab — export one GLB
  4. When ready, continue to M04 — Firmware–Twin Co-simulation

References and Further Reading

Section titled “References and Further Reading”

Course / host

Section titled “Course / host”
  1. M01 Twin Architecture · M02 VS Code Twin
  2. Course 1 M05 Sensors
  3. Bitstream Studio
  4. TESAIoT_Hackathon
  5. TESAIoT Developer Hub
  6. ternion-3d-assets-free — assets/
  7. sample-virtual-device.template.json
  8. blender-twin-cheatsheet.md

Blender — official manuals & training

Section titled “Blender — official manuals & training”
  1. Blender download
  2. Blender Manual 4.5 LTS · Manual (latest)
  3. Modeling — meshes introduction
  4. Modeling section
  5. Materials introduction
  6. Principled BSDF
  7. UV editing · UV unwrapping
  8. Texture Paint
  9. Animation introduction
  10. Keyframes · Actions
  11. Armatures · Shape Keys
  12. glTF 2.0 importer/exporter (4.5)
  13. Blender Fundamentals 4.5 LTS
  14. Fundamentals — Modeling chapter
  15. INC111-2021 Blender tutorial playlist (Thai)
  16. Khronos glTF

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: building a Virtual Device and an event script

Lab · Device checklist · Blender cheatsheet · ← Table of Contents · ← M02 · M04 →

Review questions

Answer on your own first, then open the answer.

  1. ทำไมต้องใส่ `min` / `max` ให้เซ็นเซอร์ในโมเดล (Objective 1)

    1. เพื่อให้ Simulator ทำงานเร็วขึ้น
    2. เพราะรูปแบบ glTF บังคับ
    3. เพื่อใช้เป็นชื่ออุปกรณ์ในรายงาน
    4. เพื่อกันเทสที่อยู่นอกโลกจริงโดยไม่ตั้งใจ
    Show answer

    Answer: D. เพื่อกันเทสที่อยู่นอกโลกจริงโดยไม่ตั้งใจ

    ตารางในหัวข้อ 2.3 Defaults, ranges, and honesty

  2. ข้อใดเป็น behavior ที่ “ทดสอบได้” ตามแนวทางของบทเรียน (Objective 2)

    1. เปิด Simulator ค้างไว้ทั้งวัน
    2. WHEN temperature > 40 °C for 2 s THEN emit event "temp_high"
    3. ค่าอุณหภูมิขยับบนกราฟ
    4. โมเดล 3D ดูสมจริงขึ้น
    Show answer

    Answer: B. WHEN temperature > 40 °C for 2 s THEN emit event "temp_high"

    หัวข้อ 3.1–3.2: behavior ต้องมีข้อตกลงว่าเมื่ออินพุตเกิดแล้วควรเกิดอะไร ถ้ามีแต่ค่าขยับจะวัดไม่ได้ว่า logic ถูก

  3. รูปแบบไฟล์ที่บทเรียนแนะนำสำหรับส่งโมเดลเข้า Bitstream Studio / Twin เว็บ (Objective 3)

    1. STL
    2. OBJ
    3. .blend
    4. glTF Binary (.glb)
    Show answer

    Answer: D. glTF Binary (.glb)

    หัวข้อ 5.5: .glb เป็นไฟล์เดียวที่รวม mesh, materials และ animation ส่วน STL/OBJ/FBX ใช้ในงานต้นแบบ

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, Behaviours, Event Scripts and 3D Models for the Twin" 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, behavior, event script และโมเดล 3D สำหรับ 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/m03-virtual-device/l01-virtual-device-modeling/

This lesson adapts the source below; keep its credit too.
https://github.com/drsanti/TESAIoT-Courses/blob/287c21814ba8c75f693136616dcd270349a15966/C2/M03/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