Webel Radio Net: 'radio' SysML Package Diagram with high level view of Port types for 'Radio' Signals

Gallery

Tutorial

[TRAIL] SysMLv1: The Webel Radio Net port-based messaging example model in Cameo Systems Modeler and Cameo Simulation Toolkit

Section

Webel Radio Net: Model overview, exchange items, and Ports

Tags and keywords

Topic level

INTERMEDIATE

UML keywords

Signal

Keywords

Slide kind

SysML Package Diagram

The 'radio' Package just defines a Signal Radio and associated InterfaceBlocks for use as Port types. The InterfaceBlock F_RadioPlex nests 'o' and 'i' Ports of type F_Radio and ~F_Radio, which are "conjugated" in ~F_RadioPlex.

Click on the image to view it full size

You might well be asking why Signal Radio does not have any attributes such as f:RadioFrequency (which could then be conveniently inherited). If it were not for this quirk in Magic Model Analyst^® (Cameo Simulation Toolkit^®) they would!

ISSUE: Cameo Simulation Toolkit: v2024x: Does not show argument Pins corresponding to inherited attributes of Signal on SendSignalAction or an un-marshalling AcceptEventAction. No known UML2.5.1 or fUML-1.4 constraint; no obvious tool display option.

ISSUE: Cameo Simulation Toolkit: v2024x: Although does not respect inheritance of attributes of Signals on SendSignalAction or un-marshalling AcceptEventAction DOES require them on 'effect' Behaviors.

We'll deal with that when we see the more specific RadioMessage types, which are in a separate Model package.

Looking ahead to how the Ports will be used and connected on RadioStation items in the final RadioNet:

In the Webel Radio Net model radio message transmissions are NOT handled as "broadcast to the ether", even though in a real system (and despite some beaming directionality) multiple radio stations receivers might receive ("intercept") a radio transmission intended for one recipient. Instead, a radio routing hub is used, with a single «simplex» Connector from each station (o)ut Port to a hub (i)n Port, and vice versa, where the connected Ports are nested on InterfaceBlock F_RadioPlex and its "conjugating" ~F_RadioPlex. The overall effect of the system may still be half-duplex or full-duplex.

We'll see exactly why an intermediary radio routing hub is used later, but first, let's examine the more specific RadioMessage family of Signals.

Up next

Webel Radio Net: The RadioMessage Signals

Notes

[ASSERTION, MODELLING, PATTERN]{STRONG} Webel: SysML: Heard of "follow the money"? In MBSE we "follow the flows"! Identify requests, data packets, messages, signals early on and use ItemFlow as often as you can wherever you can! Adopt a signal processing mindset throughout (systems thinking).

[GOTCHA, ISSUE, MODELLING, TOOL]{INFORMATIVE} ISSUE: Cameo Simulation Toolkit: v2024x: Although does not respect inheritance of attributes of Signals on SendSignalAction or un-marshalling AcceptEventAction DOES require them on 'effect' Behaviors.

[ISSUE, MODELLING, TOOL]{INFORMATIVE} ISSUE: Cameo Simulation Toolkit: v2024x: Does not show argument Pins corresponding to inherited attributes of Signal on SendSignalAction or an un-marshalling AcceptEventAction. No known UML2.5.1 or fUML-1.4 constraint; no obvious tool display option.

[CONVENTION, STYLE]{RECOMMENDED} In most Webel examples, the default is chosen to be 'out' if there is a single FlowProperty, so a Port with the type applied will act as a source. If an InterfaceBlock is used, then a Port typed by the conjugating ~InterfaceBlock will act as a sink.

[NAMING, POLICY]{STRONG} Webel: For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions]. The trailing part (after the underscore '_') may indicate the type that flows.

Snippets (quotes/extracts)

Visit also

Visit also (backlinks)