# ImsDT: generated twin, and what the model did not say

Generated by `cameo2vsi.py`. Do not edit: regenerate.

## Read from the model

- 7 components, from the part properties of the system block.
- 88 signal links across 7 connectors, direction taken from the flow properties and port conjugation.
- software critical path per frame: 2300 us across 6 timed actions, which is 23.0 fabric steps at 100 us per step. The software is not atomic.
- mission software: activity 'Fuse And Transmit' on MissionProcessor, 10 nodes, 10 edges, every action bound to a duration.
- 4 message types with ethertypes, read from the model.

## Decided by the config, not the model

Each of these is a twin-construction decision. The model does not carry them because a systems modeller does not specify them.

| Decision | Value |
|---|---|
| implementation language of `CommunicationArray` | Python |
| implementation language of `MissionProcessor` | C++ |
| implementation language of `ReceiverVendorA` | Python |
| implementation language of `ReceiverVendorB` | Python |
| implementation language of `RuggedizedSwitch` | C++ |
| implementation language of `TargetScenario` | Python |
| implementation language of `Transmitter` | Python |
| signal type, every signal | `int` |
| fabric step | 100000 ns (100 us) |
| total simulated time | 100000000 ns (100 ms) |
| mission software realisation | embedded, on MissionProcessor |

## Protocol to gateway, and what each substitution costs

| Model protocol | VSI gateway | Fidelity |
|---|---|---|
| Ethernet | GenericPayload | modelled, not transported |
| RF | GenericPayload | not modelled, injected |

**Ethernet.** VSI's tcpIp gateway is hub and spoke with at most two VSI ports per socket, so a five-endpoint switched network does not fit it. The switch's Ethernet behaviour (serialization, store and forward, per-port output queueing) is therefore computed INSIDE the RuggedizedSwitch component and carried over GenericPayload signals. The queueing physics is real and parameterised from the model; the wire protocol is not. This is the single most important caveat in the demo, because the whole system now runs on one Ethernet network and the switch is where contention happens.

**RF.** Both RF interfaces are marked modelled=0 in the model itself. DetectionEventIF is the RF the receivers observe and RfTransmitIF is the transmitter's feed to the communication array. The study does not simulate either medium: detections are injected past the receivers' RF front end, and the emission is timestamped at the array rather than propagated. Keeping both in the model, marked, is how the boundary of the study stays visible instead of being an unstated omission.

## Software action durations

The activity says what happens and in what order. It does not say how long each action takes, so each is bound to a value property on `MissionProcessor`. **No action is instantaneous**: at a 100 us fabric step, the shortest action below still occupies whole steps, so the software consumes simulated time exactly as the hardware does.

| Action | Duration | Bound to | Fabric steps |
|---|---|---|---|
| Await Receiver Reports | 0 us | config literal | 0.0 |
| Combine Message | 300 us | combine_us | 3.0 |
| Issue Degraded Command | 150 us | dma_irq_us | 1.5 |
| Issue Transmit Command | 150 us | dma_irq_us | 1.5 |
| Open Collection Window | 100 us | config literal | 1.0 |
| Parse Receiver A Report | 1200 us | parse_a_us | 12.0 |
| Parse Receiver B Report | 400 us | parse_b_frag_us | 4.0 |
| Window Expired | 0 us | config literal | 0.0 |
| done | 0 us | config literal | 0.0 |
| start | 0 us | config literal | 0.0 |

## Every port mapping

- CommunicationArray.rfIn: model protocol RF -> VSI gateway GenericPayload (not modelled, injected)
- MissionProcessor.eth: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- ReceiverVendorA.eth: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- ReceiverVendorA.rfIn: model protocol RF -> VSI gateway GenericPayload (not modelled, injected)
- ReceiverVendorA: model ports eth and rfIn MERGED into one VSI port 'eth_rfIn', because vsiBuild allows one port per protocol per component and protocols Ethernet and RF all map to GenericPayload. Signal names keep their model port prefix, so the merge loses no traceability.
- ReceiverVendorB.eth: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- ReceiverVendorB.rfIn: model protocol RF -> VSI gateway GenericPayload (not modelled, injected)
- ReceiverVendorB: model ports eth and rfIn MERGED into one VSI port 'eth_rfIn', because vsiBuild allows one port per protocol per component and protocols Ethernet and RF all map to GenericPayload. Signal names keep their model port prefix, so the merge loses no traceability.
- RuggedizedSwitch.portRxA: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- RuggedizedSwitch.portRxB: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- RuggedizedSwitch.portMp: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- RuggedizedSwitch.portTx: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- RuggedizedSwitch: model ports portRxA and portRxB and portMp and portTx MERGED into one VSI port 'portRxA_portRxB_portMp_portTx', because vsiBuild allows one port per protocol per component and protocols Ethernet all map to GenericPayload. Signal names keep their model port prefix, so the merge loses no traceability.
- TargetScenario.detOut: model protocol RF -> VSI gateway GenericPayload (not modelled, injected)
- Transmitter.eth: model protocol Ethernet -> VSI gateway GenericPayload (modelled, not transported)
- Transmitter.rfOut: model protocol RF -> VSI gateway GenericPayload (not modelled, injected)
- Transmitter: model ports eth and rfOut MERGED into one VSI port 'eth_rfOut', because vsiBuild allows one port per protocol per component and protocols Ethernet and RF all map to GenericPayload. Signal names keep their model port prefix, so the merge loses no traceability.
- action 'start' duration 0 us is a config literal, not a model value
- action 'Open Collection Window' duration 100 us is a config literal, not a model value
- action 'Await Receiver Reports' duration 0 us is a config literal, not a model value
- action 'Window Expired' duration 0 us is a config literal, not a model value
- action 'done' duration 0 us is a config literal, not a model value
- action 'Await Receiver Reports' takes zero simulated time: a wait, not work. Its duration is data dependent: the interpreter holds the activity here until both reports have arrived or the collection window closes, so binding a fixed cost would be wrong.
- action 'Window Expired' takes zero simulated time: DecisionNode: control, no work
- action 'done' takes zero simulated time: ActivityFinalNode: control, no work
- action 'start' takes zero simulated time: InitialNode: control, no work
- mission software realisation is 'embedded': the activity is generated into MissionProcessor's own on_step, so hardware and software timing advance on one clock.

## Requirements the run is checked against

| Id | Budget | Text |
|---|---|---|
| PR-01 | budget_us=18000 | The combined message shall be handed to the Communication Array no later than 18.0 ms after frame start. |
| PR-02 | period_us=20000 | The combined message shall be transmitted at 50 Hz. |
| PR-03 | max_age_us=20000 | Every combined message shall carry reports from both receivers taken within the current frame. |
| PR-04 | max_drops=0 | No receiver report shall be discarded under nominal target load. |
| PR-05 | max_net_drops=0 | The mission network shall not drop frames under nominal load. |