What VSI is and how a twin runs

Innexis Virtual System Interconnect (VSI) is a simulation backplane. You describe a set of components, the ports each one has, the protocol each port speaks and the signals that cross between them; VSI generates one program per component plus a fabric server that carries the packets between them in simulated time. Each component runs as its own process. The fabric server owns the clock, advances it in fixed steps, and delivers every packet a component sent during a step to the components connected to it.

The vendor calls the description language DTDL (Digital Twin Description Language). A twin is a text file of commands, the .vsi.cmd file, read by vsiBuild. The result on disk is a twin folder holding generated C++ or Python source per component, a Makefile per component and one for the server, and a .dt file that vsiSim reads to launch everything.

The four-step flow (VENDOR, Builder and Simulator Guide 1-6)

1. Design the architecture: components, protocols, signals, simulation time.
2. Generate with vsiBuild: the command file becomes source files, headers and Makefiles.
3. Run and control with vsiSim: it starts every component and offers a control prompt where you run, step, inspect signals and exit.
4. Review and iterate.

What a component is, on this machine (EXERCISED)

A component is a process built from a generated skeleton. The skeleton has fixed code that connects to the fabric, packs and unpacks packets for the port's protocol, and advances the simulation step, plus a handful of marked user regions where behaviour goes: "Global Variables and Definitions", "Constructor", "Before sending the packet", "After sending the packet" and "Protocol's callback function". The same five regions exist in C++ and in Python skeletons, and the generated Makefile knows how to run either.

Inputs arrive through the callback, which unpacks the packet into the component's signal struct after the region runs, so a value received during a step is first visible in the next step's "Before sending" region. Outputs are sent from the fixed code right after "Before sending the packet". This one-step lag on every reaction is by construction and the checker in this workspace allows for it.

What crosses the fabric

• GenericPayload ports carry the signals declared on them as a packed struct, point to point, from a source component to one or more destinations named by connect signals.
• CAN and LIN ports carry frames. Every node that defines a frame id transmits it every step and unpacks any received frame with that id into the same fields, so a frame is a broadcast domain, not a link. A consumer must be muted or it drowns the producer (see running-and-controlling/stimulus-glue-and-rates).
• Ethernet ports carry TCP or UDP sockets between exactly two ports. In the twins built from Teamcenter here the sockets exist but no signal-level data crosses them, because Teamcenter records no signal mapping for Ethernet.
• UART and GPIO between two generated components ride GenericPayload, because vsiBuild 2026.2 has no C++ to C++ UART gateway and connects GPIO signals only to a virtual platform.

Sizes that matter

• At most 64 components per twin including a slot the fabric keeps, so 63 usable. The full Wildfire model needs grouping under owning logical blocks to fit.
• One port per protocol per component (AXI and GPIO excepted); an Ethernet port can carry many sockets of mixed roles.
• A CAN frame is at most 64 bits; the generator lays out 8 bits per signal.
• A simulation here is 10 ms: 100 steps of 100 microseconds. A 63-component twin runs it in about 100 s of wall clock, a 7-component one in about 10 s.

The twins that exist in this workspace (EXERCISED 2026-09-08)

twin	components	origin	result
Wildfire (SENTINEL-W)	63 grouped blocks, all C++	Teamcenter ICD, wildfire_grouped.vsi.cmd	177 of 177 links verified, 18 of 18 producer rates
Wildfire, mixed	59 C++ and 4 Python	same ICD, wildfire_py.vsi.cmd	177 of 177, 18 of 18
MSP-2 Candidate A and B	7 each, C++	Teamcenter ICD	scripted scenario matched
MSP-2 plus a SysML-only block	7 C++ and 1 Python	sysml/Msp2_A_sysmlblock.sysml	14 of 14, 10 of 10

Traces for each run are kept under innexis-vsi/runs/ with the checker output that judged them. Twin folders themselves are regenerated by vsiBuild and are not tracked.