Behavior trees fix virtual commissioning’s test harness, not the simulator
Behavior Trees Do Not Fix Virtual Commissioning — They Fix the Test Code Around It
Forester targets the real bottleneck: test orchestration, not simulation fidelity
The hard part of virtual commissioning is not the digital twin or the simulator — it is writing and trusting the test harness. Behavior trees earn their place only once scenarios, concurrency and fault injection multiply; below that threshold, a scripted framework is fine.
Why plain code breaks down
Using an existing Python/C++/Rust test framework starts simple but degrades fast: retry loops get copy-pasted everywhere, global state bugs creep in, and invariants end up scattered across a hundred if-statements. The PLC keeps running its own state machine regardless — the orchestration layer, not the twin, is what turns unreadable.
What a BT actually replaces
- 01Load production PLC/robot packages
same binaries that ship to the real cell
- 02Point at simulation instead of hardware
- Twin reacts as if real
- Ad-hoc test code (retry loops, globals, scattered if-checks)
- Behavior tree replaces step 4
sequence / fallback / parallel / decorators
The example cell Forester is tested against
Step logic itself stays in the bridge or the PLC — the BT only orchestrates and asserts.
Scripted test code vs. behavior tree orchestration
Ad-hoc framework (Python/C++/Rust)
- Retry loops copy-pasted per scenario
- Global state bugs
- Invariants scattered across many if-statements
- Hard to hand to non-programmers
Behavior tree (Forester)
- Retry/timeout/inverter as reusable decorators
- Sequence/fallback/parallel as typed composition
- Invariants expressed as explicit nodes
- Higher-order trees packageable for industrial engineers
The collaboration angle
The author's stronger claim is organizational, not technical: once the BT logic is packaged into a reusable framework, test authorship can be handed to industrial engineers rather than staying locked with software engineers. That is framed as the real payoff — a shared artifact both sides can read and trust — but it depends on upfront investment building that packaged framework, which the source acknowledges but does not detail.
When a BT is worth adopting, per the source's own test
- 01
Multiple scenarios need to run against the same cell
- 02
Concurrency between actors (e.g. two robots, shared zone) is involved
- 03
Fault injection is part of the test plan
- 04
Non-programmers (industrial engineers) need to read and trust results
What is asserted vs. what is demonstrated
Forester adds three (unnamed in excerpt) features that make BTs viable for industrial orchestration beyond game AI.
The PLC keeps running its state machine; the BT runs against it, not inside it.
Two-robot batten/staple cell with PLC zone-mutex arbitration and camera verification.
No concrete before/after metric (time saved, bugs caught, engineer-hours) is given for BT vs. scripted approach.