Tags and keywords
If you are following this tutorial trail closely it's important that you inspect this diagram carefully, as it is crucial to understanding the net session initialisation, opening, and joining sequences we'll see simulated, and has some important information on some foibles of Magic Model Analyst® (Cameo Simulation Toolkit®) and how to deal with them.
Recall that one common principle of Radio Nets adopted in the model is the use of a scheduling channel separate from the main radio communications, which scheduling channel may be via an alternative communication channel other the main radio channel. In the Webel Radio Net model, all negotiation related to details of the net session and successful joining must be performed via the ScheduleMessage families of Signals before any radio messages may be exchanged.
Purely for the sake of comparison in the model, the Ports for scheduling are inout Ports (whereas we'll see later that the radio Ports are nested). The F_Schedule and conjugating ~F_Schedule Ports both extend I_TargetALH, which enables them to integrate with the uniform programmatic Signal routing system for a routing hub employing the Action Language Helper (ALH) API via Groovy scripts.
A main challenge simulating message systems with Magic Model Analyst® (Cameo Simulation Toolkit®) (as of v2024x) is this:
Because of these issues, attributes across the Signal families have to be tediously "manually" repeated, not just inherited! And since the order of attributes must correspond exactly to the Parameter order of any Transition effect Activities, special care must be taken with the order.
The abstract ScheduleMessage extends AnyMessage so that it can participate in the programmatic ALH-driven uniform message routing system of AbstractHub (which is extended by SHub for routing scheduling messages).
There are two sub-families of Signals under ScheduleMessage. The MessageNCS sub-family is for scheduling messages sent from the Net Control Station (NCS) to a Participating Station (PS). The MessagePS sub-family is for scheduling messages sent from a Participating Station (PS) to the Net Control Station (NCS).
A SessionToken is used as a proxy for authorisation. It merely carries a "hard to guess" UUID specific to each net session, and the StationID of the Net Control Station (NCS). The token is distributed to each Participating Station (PS) by the NCS via the InitSession Signal, along with the RadioChannel with its session-specific RadioFrequency.
There are some important policies (recalling that formal Requirements Analysis is mostly replaced in the Webel Radio Net model by «!POLICY» and «!CONVENTION» editorial comments):
«!POLICY» All scheduling messages MUST have an idSrc:StationID and idTgt:StationID for use by the scheduling message routing hub for dispatch of messages to intended recipients, where the StationID is an Integer.
«!POLICY» All scheduling Signals MUST have a token:SessionToken unique to a net session EXCEPT RejectJoin!
The reason for the token exception for RejectJoin is that if a RequestJoin attempt was rejected by the NCS because of a wrong token from the PS it's not secure to send the active token back!
There is also an "additional" SysML Enumeration SignalKindS that extends the abstract SignalKind and is used for extra simulation console "echo" diagnostics, where the Enumeration literals correspond to Signal names.