Friday 27 April 2018

Different port types in an OMG SysML model (the old pre SysML 1.3 vs new 1.3+)

This post covers a brief introduction to the different port types in a Rhapsody SysML project (8.2.1 and 8.3).

Standard UML ports

The port named ‘pOC’ here is a standard port contracted with standard UML Interfaces. Ports are named interaction points used for isolating Blocks/Classes.

Recognisable with the lollipop and cup symbology, the lollipop tells us the port is contracted to provide the iSubsystem interface.

The cup tells us that it requires the iConsoleAck interface.

The «interface» is a type of class in UML that lists the signatures of operations provided independent of implementation.

This notation is core to component-based design of software with UML2, hence works well with software-centric system modelling. Although deprecated from SysML it remains important in UML, and is still widely used in SysML and systems models, due to its flexibility and power. For example, a single port can provide or require multiple interfaces

If you make use of these, then you may also find you are making use of object-orientated features of UML (such as polymorphism). For example, a behaviour port is one where the Block itself will realize the provided interfaces on the port.

When using standard ports where the port is connected to other parts that provide or require interfaces, separate interfaces need to be used to show the operations in each direction, i.e. a single interface cannot show bi-directional services/operations. Also UML ports are service-orientated; hence they cannot show the flow of data or objects.

SysML proxy ports

The second port type shown here is a SysML proxy port, recognizable by the «proxy» stereotype. There is no lollipop and cup symbology. Proxy ports interfaces are described using a new type of Block introduced in SysML 1.3 onwards called an «InterfaceBlock». Rather than using the Contract tab in Rhapsody, the port is typed by the «InterfaceBlock» that describes the contract.

Use of the «directedFeature» stereotype allows specification of direction as provided or required. Unlike with standard ports, single interface block can therefore show bi-directional interfaces between two Blocks.

The provd and reqd annotations in the «InterfaceBlock» compartment show us the directedFeature settings.

As with UML and pre SysML 1.3 ports, the ~ tells us that this port is ‘conjugated’, i.e. it mirrors or provides the reverse of the interface.

Unlike the UML port we can also show data or object flows, not just operations and invoked behaviors. For example, if we add flow properties then we can see that a direction indicator is also shown.

With a proxy port we can therefore manage the bi-directional signals sent between two components on a single «InterfaceBlock».

In some ways, therefore, this is a simplification.

SysML Flow Ports (pre 1.3)

The third type of Port shown here is a pre-SysML 1.3 Flow Port.

Flow Ports were typed by a SysML concept called «FlowSpecification», an interface concept focusing on data or material that flows designed to allow systems engineers to model aspects like the flow of physical properties.

These concepts have been replaced by the ProxyPort and InterfaceBlock, respectively, hence a direct translation of this to the SysML 1.3+ proxy port notation is possible.

One area where FlowPorts can still be useful is where you want to show discrete signals typed by primitive data types.

When modelling such concepts, a separate InterfaceBlock for each port would lead to a plethora of model elements in the browser which is both difficult to maintain and would bloat a model. This notation is commonly used for integration with Simulink Blocks, and can be desirable for automotive models.

Until the SysML standard and Rhapsody tool fully support primitive types using Proxy ports therefore, the presence of Flow Ports is likely to remain.

Also, you may find that there is code or event generation possible with flow ports, not supported in model executable with proxy ports.

SysML Full Ports (1.3)

The final type of port shown here is a Full Port, which can be thought of as “a part on the boundary”. A full port is most commonly typed by a Block itself. 

The different with a proxy port is that the Block will realize the behaviours of itself. Using Full Ports typed by Blocks, the concept of conjugation does not really exist. They are more commonly used to represent physical connections. Another way of doing the way thing would be to create a part and use proxy ports with an InterfaceBlock.

In summary:

Full Ports were also introduced in SysML 1.3. They represent a part on the boundary. More commonly used when modelling a physical assembly, as they provide a clear graphical representation that can be shown as connected to the outside world. They tend to be used less, and some authors suggest that modelling with non-behaviour proxy ports may offer more consistency as the part is then shown inside the owner.

Standard Ports are UML ports and make use of UML Interfaces. If you use them then you are essentially modelling with UML in a SysML model (which to be honest may be perfectly fine). They make use of the cup and ball (aka lollipop and cup) symbols to show the provided and required interfaces contracted on a port.

The more correct SysML port nowadays tends to be a Proxy Port. Proxy ports are typed by a SysML InterfaceBlock. InterfaceBlocks and ProxyPorts can show both flows and operations/messages and show them flowing in either direction.

The result of the introduction of Proxy Ports and Interface Blocks means that the need for Flow Specifications with Flow Ports becomes redundant. That said, there are still some instances where Flow Ports can be simpler, for example, want to use primitive types, and when you want to do simulation.