SysML Full Ports versus Proxy Ports

SysML Full Ports versus Proxy Ports

How to use full ports and proxy ports and what’s the difference? SysML changed the way how to model ports with version 1.3 in 2012. (see also What’s new in SysML). Besides others the new version 1.3 introduced the concept of full and proxy ports.

Full port
A full port is an element of the system. It is part of the bill of material (BOM) and could – as any other part – specify behavior and an internal structure. The type of a full port is typically a standard block. The following figure shows an extract of a forest fire detection system. The Smoke sensor has a full port that specifies the attachment of the sensor to the environment. The attachment is a part of the Smoke sensor with it’s own structure specified by the block Attachment.

Smoke sensor with a full port

Proxy port
You can model the same semantics with a proxy port. The attachment is a internal part of the Smoke sensor. The proxy port provides the relevant features of the attachment to the outside. The features are specified with the interface block SIF_Attachment (SIF = System Interface).

Smoke sensor with Attachment and interface definition

The proxy port and the internal part are connected with a binding connector that assures that the instances of the proxy port and the part have the same value. For that reason the types of the port and the part must be compatible. Therefore the block Attachment is a specialization of the interface block SIF_Attachment.

Smoke sensor with proxy port

My recommodation
I recommend to use only proxy ports and to ignore full ports.

  • All parts of the system are modeled the same. There is no special case that full ports are also parts.
  • The separation of parts and their relevant features for the context puts an important focus on interfaces. Full ports provide the complete set of features of the element to the outside.
  • If every port in the model is a proxy port, you can discard the stereotype notation proxy. That makes the diagrams less cluttered.


3 Responses

  1. Jan Klostermann says:

    I do like your argument a lot and was starting to follow it.

    It has a severe problem though:
    It does not allow the decomposition of ports and connectors as shown in or the standard itself ( 9.4.5 Association and Port Decomposition, SysML 1.4 Standard, page 91f.)

    At least in my tool (PTC Integrity Modeler, aka Artisan) I cannot create a simple association between two interface blocks. Therefore I cannot link an association block to them either. (I remodeled the example from the blog article above, replacing all full ports with proxy ports and Pin/Socket and DB-9 Male/Female as interface blocks, getting stuck already at the bdd. With full ports it works beautifully.)

    Is this just a bug in my tool or is this a general SysML restriction that makes this combination of ProxyPorts/InterfaceBlocks with association blocks inaccessible.

    Any comments are very welcome.
    Thanks for considering.

    • In SysML it is allowed to have associations between InterfaceBlocks. It is not allowed that an InterfaceBlock has composite properties. If you use an association or aggregation relationship you do not get composite properties.

      As a workaround you can try to define a stereotype that specializes the SysML stereotype fullPort and name it, for example,_proxy. That means you use the full port model element for the proxy port concept in your tool. If the tool allows it you could also define the proxy port constraints at your new stereotype.

  2. […] Hier sehen wir, dass das iPhone einen Lightning-Anschluss hat, der als Proxyport modelliert wurde. Warum wir auf „Full Ports“ verzichten sollten, beschreibt Tim Weilkiens in diesem Artike…. […]

Leave a Reply

Your email address will not be published. Required fields are marked *