systemmodelingsysmlmagic-draw

What element type should I use to model a message and its data elements in SysML?

In SysML, when modeling a message, I'm having trouble understanding what element type should be used to define it, its elements, and a port that it flows through.

I'm assuming it is either:

Both can type a proxy port (formerly flow port, if I understand correctly), or type most other properties in other blocks as one builds up a full message interface or port system (either straight ports or nested ports). If the base message definition is a normal block, then when do you create a flow property that gets typed by that block, so that something can actually flow from one task to another through the port?

An Interface Block should occur somewhere in there, in order to type the port, right? Does that mean I use it to define a message directly, or does that depend on my port scheme (i.e. whether I nest ports and to what level)?

I guess this boils down to confusion over when you are defining a thing (i.e. a class/block) and when you are defining that this thing is a quantity that flows in your model (a flow of some kind - the message passes from one task or piece of hardware to another).

P.S. I'm using MagicDraw as the SysML tool, but I don't think that should impact the core answer.

Solution

  • The answer, as developed by my team:

    1. Use a full port for the raw network interface, the physical layer.
    2. Use a block to type the network interface, including:
      • Flow properties that represent physical items flowing out of the port, such as total electrical current (power).
      • Nested full port elements for physical nested ports, such as pins that make up a physical ethernet port. Type with another block.
      • Nested <> elements for logical/abstract data flows across the network interface, such as sockets/connections
    3. Use an Interface Block to type each logical connection (nested proxy port) with an Interface Block containing the following:
      • Flow properties that represent blocks of data, such as messages, which are sent as a group across the connection
      • Value properties that define characteristics of that connection, such as source and destination IP addresses and port numbers, comm loss and retry info, etc. Note some of this may be better served as meta data in tags as part of a separate stereotype.
    4. Type the data flow properties of the connections with a ValueType whose attributes are the individual data elements of that data block (i.e. the message elements).
    5. Create a new stereotype with a custom name something like "Data Element" and add tags for any meta-data that is needed about each data element, such as length (in bits or bytes), underlying type in the message, any unit or scaling factors, position in the message, etc.

    You can even create a generic table at this point which will list every data element in a given message, or in all messages, and add all the relevant Data Element tags as columns, and use it as a current specification for each message and data element of each message, and allow much easier editing of all the information directly in that table.

    Why use ValueTypes for data blocks that flow across Proxy Ports? Because then they will show up as Information Flow items instead of Item Flow items across a connector between two Proxy Ports on an Internal Block Diagram (IBD). I.e. when I send a physical item, typed by a Block, it is sent as an Item Flow, but when I send a logical item, such as data, it is typed by a ValueType, and sent as an Information Flow.

    This is a starting point - we found issues with nesting the valuetype definitions initially, so opted for a much flatter message definition that contained all the aspects of a message in a single ValueType, rather than nesting them. I'm sure there are ways around this, but how complicated do you want to get?