Tags and keywords
This is another relatively complex Diagram that you should please study carefully before proceeding, or you may not fully understand the rest of this tutorial trail or the final radio message simulation.
In a real world situation, radio transmissions typically "carry" a radio message within them (the precise details depend on whether digital or analog and the mechanism used). This invites modelling the transmission of radio signals separate from the message "packets" they carry. However, this makes it harder to follow in Cameo Simulation Toolkit, since the animation of Signals along Connectors does not display their content. Also, if one were to use a Block to model the radio message "packet" and have it wrapped by Radio to send it, it would means there is more packing/unpacking modelling work.
Therefore, a compromise was used; there is a Signal type Radio - which defines the type of the FlowProperty on radio ports - and an extending abstract Signal type RadioMessage, which defines a family of radio messages.
The abstract RadioMessage extends Radio, which extends AnyMessage, so it can participate in the common Signal handling using the Action Language Helper (ALH) API and the AbstractHub (extended by the radio routing hub RHub, which we'll examine in more detail a bit later).
There are some radio message policies:
«!POLICY» All radio message payloads are passed via the NCS.
«!POLICY» All concrete radio messages MUST have an attribute f:RadioFrequency.
«!POLICY» All concrete radio messages MUST have attributes 'idSrc' and 'idTgt' of type StationID for use by the radio routing hub for dispatch of messages to intended recipients!
Note that the 'idSrc' and 'idTgt' refer to the routing by the radio hub, not necessarily the StationID of the origin (OGN) and the intended final recipient of the packet relayed via radio by the NCS between two participating stations.
As before, you might well be asking why the above mandatory attributes 'f', 'idSrc', 'idTgt' and 'token' are not defined on the abstract Signal RadioMessage and then simply conveniently inherited. If it were not for this quirk in Magic Model Analyst® (Cameo Simulation Toolkit®) they would!
And care must be taken that the order of the attributes corresponds to the order of Parameters of any 'effect' Activities for Transitions triggered by these radio message Signals.
There is an "additional" SysML Enumeration SignalKindR that extends the abstract SignalKind for use in uniform simulation console echo diagnostics. The 4 enumeration literals RRF, RFM, RCR, RCF are the acronyms that stand for the 4 concrete RadioMessage types. These also appear in many Operation and Activity names in the Webel Radio Net model.
The 4 concrete RadioMessage Signals are:
RadioRequestForward(RRF):A request (by radio) from a non-NCS participating station to forward a message (by radio) to another non-NCS station. Note the additional 'idToPS' specifying which station the packet (carried as msg:Message) is intended for.
RadioForwardMessage(RFM): The message bundle as forwarded (by radio) by the NCS on behalf of a non-NCS station (the origin). Note the additional 'idOgn' for tracking the origin station that sent the packet (required also to callback to confirm delivery).
RadioConfirmReceived(RCR): Confirmation (by radio) back to the NCS that a forwarded message was indeed received, identified by UUID. The 'idOgn' is carried on, but the message itself is not returned, just its uuid:UUID.
RadioConfirmForward(RCF) Confirmation (by radio) from the NCS that a message (identified by the UUID of the message) was forwarded AND received. The UUID of the confirmation can then be checked against the origin station's own Message logs, as we'll see in the simulation.
BTW: It's not usual Webel Best Practice to include acronyms in Element names verbosely this way, it's usually handled via an 'acronym' tagged value of a custom Term stereotype, but the acronyms are included in the RadioMessage names here just to make them extra clear during the simulation and animation.