What VSI is for: which of my problems does it catch

The useful question is not what a virtual twin is. It is which defects this finds that your current verification does not, and why those particular ones survive.

They survive for one reason, and it is structural rather than careless: every team verifies its own part, correctly, and the interaction between parts is nobody's deliverable until the parts exist.

The defect classes

Each entry says what the defect is, why conventional verification misses it, and what evidence we have. Where something has not been run here, the entry says so rather than presenting a product capability as a result.

Timing defects across a hardware and software boundary

Software meets its budget against a stub. The hardware meets its datasheet. The combination misses a deadline that neither owns.

Why it is missed. No single team's test contains both halves at once.

Exercised here. This demo. The deadline is missed only at four targets, only with the real vendor timing and the real network in play.

Stale or out-of-order data that still looks complete

A late input is silently replaced by the last good one. The message is well formed, fully populated, and wrong.

Why it is missed. Nothing throws, no counter moves, and a stub that always answers on time never produces the condition.

Exercised here. 3 of 5 messages per run carried the previous frame's data, marked complete, while latency and packet loss both passed.

Contention on a shared network or bus

Each talker is within spec. Together they queue, and the victim is whichever message was already closest to its deadline.

Why it is missed. Bench tests exercise one talker at a time.

Exercised here. Store-and-forward queueing modelled per port, parameterised from the architecture model, with background telemetry on the same switch.

Vendor black boxes you cannot execute

A supplier gives you a datasheet, not behaviour. Integration risk sits in a component nobody on your team can run.

Why it is missed. There is nothing to test against until hardware arrives.

Exercised here. Both receivers are timing envelopes only: latency, jitter, fragmentation, payload size. That was enough to find the defect.

Comparing candidate fixes before committing to one

Two plausible fixes. Both are correct. Choosing needs numbers nobody has, so the argument is settled by seniority.

Why it is missed. You cannot A/B a fix against hardware that does not exist.

Exercised here. Nine runs across three configurations and three load points, one afternoon, no hardware.

Integrating components written in different languages

A compiled model, a scripted stand-in and a supplier's FMU are supposed to be one system.

Why it is missed. They are usually only 'integrated' in a document.

Exercised here. Compiled C++ infrastructure and Python vendor models on one fabric and one clock, re-verified identical across 9 runs.

Driving the twin from the architecture model you already have

The system model and the simulation are maintained separately and disagree within a month.

Why it is missed. Nothing forces them to agree.

Exercised here. The twin is generated from the SysML model. The model carries no tool-specific content, so it stays the engineering source.

Searching the design space instead of guessing fixes

The parameters interact. Hand-picked candidates find a trade and stop there.

Why it is missed. There are more combinations than anyone will try.

NOT RUN. HEEDS is licensed here and not yet installed. The evaluation harness is built and its contract proven; no study has run.

What happens when you fix one

Rarely what people expect, and this is the part worth internalising before a programme relies on it.

In the worked example, two independent fixes each cured the defect they were aimed at, and each handed the system a different failure in its place. That is the ordinary experience of integration. A twin is valuable less because it tells you a fix works and more because it prices the trade before anyone commits to one.

What it does not do

Wire-level protocol fidelity. Ethernet is modelled inside the switch component, not transported. Frame timing, serialization and queueing are real; the wire format is not. A defect that depends on the bytes on the wire needs a different twin.

Physics and analogue behaviour. This is a discrete interaction and timing tool. RF propagation, thermal and mechanical behaviour belong to other Simcenter tools.

It does not invent what the model does not say. Vendor timing has to come from somewhere. The twin is exactly as honest as the datasheet you feed it, and every value the generator had to assume is written into an assumptions file rather than defaulted quietly.

What you need to start

• An architecture model with blocks, ports and interfaces. It does not need anything tool-specific in it, and it should not have any.
• Vendor timing from the datasheets you already hold: latency, jitter, payload size, and any per-load behaviour in the fine print.
• The software behaviour you intend to ship, as a state machine or an activity. Not a stub.

That is enough. In the worked example the build took 118 seconds, each scenario after it took about 90, and the campaign was 9 runs in an afternoon.