Ports, item flows and aggregation in a ground-station structure model
A ground-station model is under review before an interface control document is generated. Block AntennaStation owns parts antenna : Antenna [1], receiver : Receiver [1] and a shared powerDistribution : PowerBus [1]. The receiver's input is a port rfIn typed by RF_Interface, whose flow properties are out rfSignal : RF_Signal and out status : HealthStatus. On the internal block diagram a connector joins antenna.rfOut to receiver.rfIn with no item flow; the engineer's defence is that the port types already state what flows. Receiver also owns lna : LNA [2] declared with shared aggregation, on the grounds that both amplifiers should point at the same amplifier definition. The power bus is owned by the station, yet each of the three parts carries a composite aggregation end to PowerBus. Finally, antenna.rfOut is a proxy port, receiver.rfIn is a full port (isBehavior = true) with its own nested protocol state machine, and the 2.4 Msymbol/s link rate appears only in a comment attached to the connector.
1. Is the connector between the proxy port and the full port legal? Explain the proxy/full distinction, and why the flow directions as described will not work without conjugation.
Read the worked answer
The connector itself is legal: a proxy port and a full port can be joined, since the proxy/full distinction concerns what the port owns, not what it can connect to. What is not legal is the direction. rfOut is typed by RF_Interface with out rfSignal, and rfIn is typed by the same block, so rfSignal is also declared out on the receiving end. Joining out to out describes two sources and no sink; tools will either reject the connector or generate an incoherent interface definition.
The intended mechanism is conjugation: type rfIn with a conjugated use of RF_Interface (isConjugated = true, shown as a tilde before the type or port name), which inverts every flow property's direction so rfSignal becomes in on the receiver and status becomes out toward the antenna. Defining a second mirrored interface block works too but duplicates a definition and drifts.
The proxy/full distinction is orthogonal. A proxy port is a "small" port whose features are those of its type and which delegates interaction to internal parts; it has no state of its own. A full port (isBehavior = true) is a "deep" port that may own behaviour or state, as this one does with a protocol state machine, and it is the right choice for a receiver that negotiates a link. Two consequences to check: if Receiver has isEncapsulated = true, its internal parts cannot be reached from outside and all interaction must route through ports, which is what you want here; and the port's state machine must actually be driven, so the connector must carry the item flow that triggers it.
2. What does adding an item flow contribute when the port types already declare the signals? Where should the 2.4 Msymbol/s rate live, and what goes wrong if it stays in a comment?
Read the worked answer
Port types answer "what may flow through this interaction point". An item flow on the connector answers "what does flow here, in this specific assembly". The first is capability, the second is fact. Without the item flow, a reader, a tool or a subcontractor cannot tell whether rfSignal actually traverses this connector or whether the antenna is merely capable of emitting it; generated interface documents come out empty, and an allocation or verification query that follows items through the structure finds nothing. Add an item flow conveying rfSignal : RF_Signal, optionally with its own item property so the conveyed entity can carry rate or power attributes.
The 2.4 Msymbol/s is a quantity and belongs in the model: a value property symbolRate : Frequency on RF_Signal or on RF_Interface, typed by the ISO 80000 frequency value type with unit Hz or MHz so dimension is captured. The link-rate requirement is then satisfied by the element that owns the value (the interface block, or the Receiver that realises it), and a constraint property on the interface can state symbolRate is at least 2.4e6, evaluated in a parametric diagram.
A comment on a connector is invisible to every check the model can perform: it carries no unit, no traceability to the requirement, no verification link, and it does not appear in any diff when the requirement changes. Keep comments for rationale; put numbers in value properties.
3. Untangle the two aggregation decisions. Was shared aggregation needed on lna : LNA [2], and what is wrong with three composite ends pointing at the station's power bus?
Read the worked answer
Two different concepts were merged.
Type re-use is a modelling-efficiency mechanism: one LNA block, many properties typed by it, all sharing the definition and none sharing an instance. That is what the engineer actually wanted, a common amplifier specification. Aggregation concerns instances: composite means the whole owns the part, the part's lifetime is bound to the whole, and one instance cannot be a composite part of two wholes; shared or none means the property references an instance that may be shared. With lna : LNA [2] declared composite you get two distinct LNA instances, which is exactly right for two physical amplifiers and does not conflict with both being typed by the same block. Shared aggregation buys nothing here and misleads readers into thinking the two properties denote one amplifier. Keep it composite.
The power bus is the reverse problem. PowerBus is owned by the station, yet each of the three parts carries a composite end to it. Three composite ends from three different wholes to one bus instance asserts triple ownership of a single instance, which is not well-formed, and it breaks the instance model: deleting any one part would delete the bus the others still use. Model the bus once as the station's part, powerDistribution : PowerBus [1] with composite aggregation from AntennaStation, and give antenna, receiver and the rest reference properties (aggregation none) or navigable association ends to it. That captures sharing at instance level and gives the bus exactly one owner. Re-run any ownership query afterwards; the change should reduce the count of multiply-owned instances to zero.