Read from the model, not a run: innexis-vsi/demo-hwsw/ims.answers.json
(the link list) and ims.params.json (the modelled flag). Nothing here changes between
runs, because it is not a claim about a run.
Solid blue: Ethernet, one port per LRU, all four meeting at the switch.Dashed purple: RF, declared "modelled": 0 in the model itself, bypasses the
switch entirely.
Every bus, and how many signals it carries
Link
Bus
Signals
ReceiverVendorA
Net_ReceiverA
18
ReceiverVendorB
Net_ReceiverB
18
MissionProcessor
Net_MissionProcessor
18
Transmitter
Net_Transmitter
18
TargetScenario -> ReceiverVendorA
Rf_DetectionA (not modelled)
5
TargetScenario -> ReceiverVendorB
Rf_DetectionB (not modelled)
5
Transmitter -> CommunicationArray
Rf_Transmit (not modelled)
6
This fixes a merge the twin introduces that the model does not have. The twin's
generator merges Rf_DetectionA and Rf_DetectionB, which is why ims-twin.html shows TargetScenario feeding both receivers over
one bus. The model declares them separately, so this page, reading the model, draws two.
ims-twin.html shows the twin's own wiring correctly for what it is: a picture of the
generated twin, not the model.
"Physical" is the model's own declared wiring, not a photograph. IMS is a
fictional system; nothing here was measured with a cable tester. What grounds this page
is that it is READ from the model's link list and its own modelled flag, not written from
a description of what the components probably look like.
Generated by
make_physical_topology.py from ims.answers.json and ims.params.json in
innexis-vsi/demo-hwsw. See also the message flow view
(who talks to whom, and when, during a run), the
frame-by-frame timeline and the
baseline-vs-fix comparison.