Digital Twin Simulation Platform

01Simulation reports engineers actually read

Before this, simulation output lived in raw log files or had to be observed live. I built the system that generates and opens a self-contained HTML report at the end of every run: per-robot joint-angle charts, tool-centre-point path charts, work-target completion statistics pulled from external tables, and a parts inventory of every asset in the scene. An offline fallback mode keeps reports generating with reduced data when external services are down.

Getting this right meant understanding the full simulation lifecycle to hook the completion event without disturbing simulation state, and designing a modular data layer, YAML configuration, live data through an internal extension at runtime, CSV fallback. Along the way I fixed lifecycle bugs around stale state on scene changes and windows closed mid-simulation, and extracted CSV parsing and file loading into dedicated modules. That config-driven pattern was reused by every subsequent feature on the platform.

02Three extensions, one architecture

I shipped a data visualisation extension rendering live records from an internal asset system into dynamic tables inside Isaac Sim (Model-View-Delegate pattern, config-driven dropdowns for car model and station filters); the DT Sim Manager landing page, built from scratch as the entry point launching the platform's simulation flows; and the New Product Introduction window, a three-state UI (pre-setup with scenario selection and clash review, active simulation, post-simulation review) with shared state across three visually distinct layouts and a custom expandable widget for clash detection.

The NPI window was wireframed in FigJam and reviewed with the team lead before any code was written, an agreed design that measurably cut implementation iteration. I also consolidated the baseline simulation from two extensions into one and redesigned the stage-load flow around USD sublayer composition: create an empty stage, add the scene as a sublayer, flatten, apply starting configuration. Understanding why the previous template-stage approach kept failing required reading Isaac Sim's own source.

03The traceability audit

The project target: over 80% of simulation assets traceable to identifiers in the factory's physical-parts systems. The report showed roughly 31%, and the working assumption was a code bug. I exported the full scene hierarchy to establish ground truth, 36 physical parts, and cross-referenced every asset against the mapping spreadsheet and the external system records, by hand.

Result: 16 of 36 traceable, or 44%. Every gap was a data problem rather than a code one: identifiers that existed in the mapping file but were never written into the scene, parts with no identifier information at all, and one asset in the simulation that no external system knew about. I wrote it up with a remediation plan ordered by root cause, so the team could fix the data instead of hunting for a bug that was not there.

04Communicating up and out

Beyond code: I wrote the Confluence documentation for the PoC's UI and reporting systems at a level pitched for three audiences, engineers maintaining it, line operators using it, leadership evaluating it. I produced video walkthroughs for user onboarding, and prepared a structured analysis of NVIDIA GTC 2026 announcements for the team and stakeholders, filtering a large volume of marketing-framed material down to what would actually affect the roadmap, with concrete recommendations.