Digital Validation before Prototyping

Course 3 · Module 5 Suggested time: about 3 hours — run usage scenarios on the Twin, pair firmware/edge AI data, then fill in a fix list before printing a prototype Format: a hands-on lesson — read it and test the scenarios directly; STL printing and the report are in M06

Lab · Pre-prototype checklist · ← Table of Contents · ← M04 · M06 →

Objectives (Learning Outcomes)

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

Set up a usage scenario (grip, place, open the lid, etc.) that the Twin can support
Assess the product’s response and use the result to improve the design
Pair the model with Edge AI / firmware data (a state → colour / clip)
Do Digital Validation and produce an improvement list before building a prototype

Key phrase Digital validation = finding design bugs on screen before wasting plastic — if you find a problem in M05 and don’t write it down, you are not ready to print in M06.

Read alongside this chapter

Document	Use when
M04 — Blender to Twin	The GLB is already ready in Bitstream Studio
M03 — Motion	The `lid_open` clip for the lid-opening scenario
Course 2 M04 / M05	co-sim · telemetry · web-app consumers
Bitstream Studio	Running the scenario on the Twin host
TESAIoT_Hackathon	`web-app/ex06` (dashboard) · ex05 (orientation)
Electronic enclosure design guide (3DDFM)	An enclosure checklist / clearance / assembly
Protolabs — Enclosure for 3D printing	Walls · clearance before printing
All About Circuits — 3D-printed enclosure steps	The PCB-first validation mindset
DFM checklist thinking (Root3 Labs)	Questions before tooling / real production
TESAIoT Developer Hub	Firmware reference when pairing a state
Pre-prototype checklist	This lesson’s main deliverable form

1. What Digital Validation Means in This Course

Digital validation in M05 is proving on the Twin that the enclosure + clips + sensor points work together with real or simulated data, before ordering a print in M06.

It is not:

A substitute for full industry-standard testing
A substitute for full impact simulation via FEA (unless you have that tool)

But it is:

[Usage scenarios on Twin]
        │
        ▼
[Observe problems]  →  thin walls · blocked sensors · lid clash · bad port
        │
        ▼
[Bind firmware / Edge AI signals]  →  color / clip / highlight
        │
        ▼
[Pre-prototype checklist]  →  Top 3 fixes before print

Enclosure/DFM concepts used alongside this check: 3DDFM enclosure guide, Protolabs enclosure guide

2. Usage Scenarios — Design the Test First

Before playing a clip, write the scenario as a short sentence: who, does what, expects to see what.

2.1 Scenario catalog (pick at least two)

Scenario ID	User action	What you watch on Twin	Pass signal
S1 — Desk place	Place the device on a desk in its normal orientation	The base sits still · the origin looks correct	It doesn’t tip over in the view / the ports are readable once placed
S2 — Handheld	Hold the device (simulate a camera angle close to a hand)	Buttons/LEDs are within finger reach	No sharp edge blocks an important button
S3 — Lid service	Open the lid 3 times using the clip	Collision · the opening angle · seeing the PCB	No intersection · opening it reveals the service compartment
S4 — Sensor access	Trigger a sensor (scene/motion/tilting the board)	The `sensor_…` point + the value on a dashboard	The sensor opening is not blocked · there is a data stream
S5 — Port plug	Simulate plugging in a cable (look at the port opening)	The USB/port opening	The opening is big enough and faces the right way
S6 — Alert state	Trigger an over-threshold event (from Course 2)	A colour/highlight on the model, or a short clip	The firmware team and the design team can point to the same spot

The lab requires at least S3 plus one more from S1/S2/S4/S5 (adding S4 or S6 is recommended if you have a data stream).

2.2 How to run a scenario (lab loop)

Open the model in Bitstream Studio
Read the scenario sentence out loud (or write it on the checklist)
Perform the action (play a clip / change the angle / trigger a sensor)
Note what you expected vs what you saw
If it breaks: log it as a fix item (don’t fix it quietly without recording it)

2.3 Optional impact / drop (concept only)

If the Twin or the tools you have have no impact physics:

Use a conceptual scenario: “if it fell off the desk, which corner of the box would take the force first?”
Note your assumption + where the walls are thin — do not claim you have actually simulated a real impact force

3. Observe and Improve the Design

During/after a scenario, watch for these symptoms (summarised from general enclosure guidance):

Risk	What it looks like	Typical fix before print
Walls too thin	The edges look sharp/thin in the Twin, or Thickness < ~2 mm	Increase thickness · add a rib in M02/M06
A sensor opening is blocked	The opening is not above the chip · something else covers it	Move the opening · cut a new one
A port is hard to plug into	The opening is small/at the wrong angle	Enlarge the opening · add clearance
The lid hits a tall part	Opening the clip clips through USB/the display	Reduce the opening angle · move the hinge · adjust box height
Hard to assemble	No place for a screw / lid separation is unclear	Plan bosses in M06 · split parts for printing
Scale is off	It doesn’t look right compared with the real board	Go back to M01/M04, fix it, and export again

Log at least 3 issues in the lab — even if some are “passes, but watch this.”

If there is time: go back to Blender and fix at least 1 spot, then export a new GLB round (review M04).

4. Bind the Model to Edge AI / Firmware Data

Goal: make the Twin a common language between the design team and the firmware team.

4.1 Binding patterns (pick one or more)

Firmware / Twin signal	Visual response on model
High temperature / a threshold event	Highlight the sensor opening area, or change the body’s colour
BMI270 orientation	Rotate the preview to match the pose (if the host supports it), or compare two screens side by side
Mode / an LED on the device	Emission or a colour change at `led_status_window`
A lid-open command from the UI	Play the `lid_open` clip

Review the data pipeline: Course 2 M05 · the points named in M04

4.2 Second screen — Hackathon dashboard

Recommended while running S4/S6:

Serve web-app/ from Hackathon
Open ex06 (multi-sensor dashboard) or ex05 (orientation)
Capture both: the Twin scenario + the live sensor values

If there is no data stream in this round, use a simulated state script in the Studio (if available), or record binding the data as a plan for M06 / Course 2 — don’t leave the gap without writing a reason.

4.3 Evidence rule

Binding claim	Evidence required
“The model responds to the sensor”	A screenshot/clip showing both the model and the value change
“The sensor opening is at the right position”	A Twin image pointing at the spot + the `sensor_…` name + (if any) the real board
“Cannot be bound in this round yet”	A short reason + what will be done in M06

5. Digital Validation Checklist (Before Prototype)

Fill in the full version in pre-prototype-checklist.md

5.1 Minimum validation columns

Area	Key question
Scale	Does the size still match the board/the M01 formula?
Internal fit	Do the PCB + battery + cables all fit together?
Sensor openings	Are the openings at the real sensor positions?
Ports	Can you plug in a cable/see the LED?
Walls	Thick enough to print (~2 mm as a starting point)
Motion	Does the lid/button collide with another part?
Twin stability	Does the GLB import reliably, and can clips play?
Data link	Is at least one state binding present, or is there a reason it isn’t yet?

Further enclosure/DFM questions for reference: 3DDFM checklist section, Root3 DFM questions

5.2 Top 3 fixes before print

The end of the checklist must have 3 fixes in priority order, for example:

Enlarge the USB opening by +0.5 mm per side
Reduce the lid’s opening angle from 110° to 95°
Increase the lid’s wall thickness to 2.0 mm

If everything passes: write “Ready to print” and state what still needs watching during real assembly.

6. Quality Gate Before M06

Check	Pass means
≥ 2 scenarios run	Expected vs actual is recorded
≥ 3 design issues or watch-outs logged	None left blank
Pre-prototype checklist filled	Including the top 3 fixes
Optional: 1 model fix re-exported	A new GLB exists if a fix was made
Optional: telemetry/web-app pair shot	Evidence of the data binding

Next Steps

Do the lab: Lab
Fill in pre-prototype-checklist.md
When ready, continue to M06 — Prototyping and Final Project

References and Further Reading

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

Continue hands-on at Lab: usage scenarios and a pre-prototype checklist

Lab · Pre-prototype checklist · ← TOC · ← M04 · M06 →

Review questions

Answer on your own first, then open the answer.

สถานการณ์ S3 — Lid service ให้สังเกตอะไรบน Twin (Objective 1)
1. การชน มุมเปิด และการเห็น PCB เมื่อเปิดฝาซ้ำสามรอบด้วยคลิป
2. ฐานนิ่งเมื่อวางบนโต๊ะ
3. ขนาดและทิศของช่อง USB
4. ค่าเซ็นเซอร์บน dashboard
Show answer

Answer: A. การชน มุมเปิด และการเห็น PCB เมื่อเปิดฝาซ้ำสามรอบด้วยคลิป

ตาราง Scenario catalog ในหัวข้อ 2.1
ถ้าอ้างว่า “โมเดลตอบตามเซ็นเซอร์” หลักฐานที่บทเรียนกำหนดคือข้อใด (Objective 2)
1. ไฟล์ .blend ต้นฉบับ
2. ภาพเรนเดอร์ EEVEE
3. สกรีนช็อตหรือคลิปที่เห็นทั้งโมเดลและการเปลี่ยนค่า
4. คำอธิบายสั้น ๆ ในรายงาน
Show answer

Answer: C. สกรีนช็อตหรือคลิปที่เห็นทั้งโมเดลและการเปลี่ยนค่า

ตาราง Evidence rule ในหัวข้อ 4.3
ท้าย pre-prototype checklist ต้องมีอะไร (Objective 3)
1. รายการแก้สามข้อเรียงตามความสำคัญ (หรือ “Ready to print” พร้อมสิ่งที่ยังเฝ้าระวัง)
2. ภาพเรนเดอร์สามมุม
3. รายชื่อสมาชิกทีม
4. ไฟล์ STL ที่พิมพ์แล้ว
Show answer

Answer: A. รายการแก้สามข้อเรียงตามความสำคัญ (หรือ “Ready to print” พร้อมสิ่งที่ยังเฝ้าระวัง)

หัวข้อ 5.2 Top 3 fixes before print

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.

"Digital Validation before Prototyping" 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: "Digital validation ก่อนสร้างต้นแบบ" จาก 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/product-design/m05-digital-validation/l01-scenario-digital-validation/

This lesson adapts the source below; keep its credit too.
https://github.com/drsanti/TESAIoT-Courses/blob/287c21814ba8c75f693136616dcd270349a15966/C3/M05/README.md · Original content by Asst. Prof. Dr. Santi Nuratch (ผศ.ดร.สันติ นุราช), KMUTT. Course 3 (C3/) 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

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