Full Ports - which nested ports are on the inside/outside?

[Johan Van Noten]

In SysML 1.4, Full Ports can have nested ports.

 

In his book "A Practical Guide to SysML", Friedenthal, Moore and Steiner write "The ports of Mount can be seen on the boundary of their parent port. Although nested ports of full ports can be placed anywhere on the boundary of their parent symbol (with the caveat noted above), the nested ports of mount have been placed so that those intended to be connected externally are shown on the outside and those intended to be connected internally are shown on the inside."

 

This is very informal: if a port is intended to be connected on the inside, then graphically position it on the inside. The decision is therefore in the notation.

 

Consider the small IBD below. The Block1 contains two parts typed by Block2, one as a "normal" part, the other as a "Full Port".

• For part1 everything is clear: both p1 and p2 need to be connected inside Block1.
• For part2 it is unclear. From their graphical position, one can derive that only p2 should be connected inside Block1.

 

In our environment, we want to introduce a validation check that warns about ports that have been left unconnected.

It is awkward to go and base such validation on the ports' graphical position.

We are rather looking for semantic information in the port that indicates which of its nested ports are intended to be on the inside.

 

Obviously, this kind of information cannot be stored inside the type (i.c. Block2) nor in a part typed by it.

The information is only required for FullPorts, so I guess the list of "insidePorts" should be defined in the FullPort stereotype.

Today, that stereotype doesn't contain any properties.

 

Do I overlook any other info in the metamodel?

Is it just not covered?

How do you use this?

 

Best regards,

Johan

 

 

 

 

 

 

 

 

 

 

[James Towers]

What kind of ports are the nested ports p1 and p2? 

If they are plain un-sterotyped 'ports' then you can extend the 'port' concept with stereotypes «internal» and «external» (as an example) if they are already stereotyped «FullPort»  then you will need to specialise that stereotype as say «internalFullPort» and «externalFullPort» that way you would be able to distinguish them in your validation and give them the additional semantics you require. 

Regards

James

<Auto Generated Inline Image 1.png>

 

 

 

 

 

 

 

 

 

 

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at https://groups.google.com/group/sysmlforum.
To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/f55765ab-4799-4ecb-823a-0b9acab395b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Auto Generated Inline Image 1.png>

[Johan Van Noten]

Hi James,

Thanks for your reply.

I use different kinds of ports in the different parts of the model.

The mechanism that you propose attaches the "knowledge" about internal/external to the port itself, which is not desired. As you can see in the example, the port p1 is internal in one part and external for the other.

My question was rather inspired by my surprise that SysML doesn't seem to have a formal notation for this quite "normal" construct/need.

If there is no solution within the default SysML spec, I will need to construct some stereotype based solution.

I agree that some mechanism with an additional stereotype for FullPorts containing a reference list to the FullPort's internal ports (subsetting all of its ports) could solve this question.

Best regards,

Johan

[Stephan Roth]

Hello anybody,

hello Johan,

since SysML 1.3 in 2012, the concept of ports have changed. There are now only two kind of ports available: Full Ports (stereotyped with «full») and Proxy Ports (stereotyped with «proxy»). The Standard Port which SysML inherited from UML and that are typically used for IT interfaces, and which are apparently used for the ports in Johan's example, has been marked as deprecated and should no longer be used.

The main difference between a Full Port and a Proxy Port is that a Full Port is nothing else than a building block of the System Of Interest. Hence, it is also an entry on the system's so-called bill of material (BOM), a list of all parts needed to manufacture the system respectively product. Ports are typed elements. The type of a Full Port is usually a standard SysML Block («block»). That means that everything that is valid for a usual Block (e.g. having structure and behavior) is also valid for a Full Port.

In contrast, Proxy Ports are not parts of the system, hence they will also not appear on the BOM. Proxy ports are always typed by interface blocks (stereotype «interfaceBlock»), a specialized kind of block that serves only as an interface definition and has no behaviors or internal parts.

The main problem with Full Ports is that they are more or less nothing else than usual parts. They play a somewhat odd "double role": on the one hand, they serve as an interaction point of their owners with the environment, but on the other hand they are just parts like all the other parts too. Thus, we at oose strongly recommend to not use Full Ports at all! You can get along without this type of port. Instead of using Full Ports, you should solely use Proxy Ports. The great advantage of this approach is that all parts of the system are modeled in the same way. There is no kind of "exceptional case" where a part is also a port. And you can create nested ports also with Proxy Ports, if needed.

So, my recommendation is to convert your Full Port named "part2" into a real part of the system (it "moves" inside the ibd), and to introduce a Proxy Port instead that is connected with "part2". I've attached an bdd and ibd to show the result.

Hope that helps!

With best regards,

Stephan Roth
Trainer, Consultant, and Coach

oose Innovative Informatik eG, Germany

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at https://groups.google.com/group/sysmlforum.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/abedce79-f123-4c48-b9ce-ae15e43fa1f8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 

Stephan Roth

[Johan Van Noten]

Hi Stephan,

I understand your point. On the other hand, we seem to have quite some advantages of modeling with FullPorts in our use cases.

We are doing Systems Engineering of mechatronics systems and there the incremental refinement of the interfaces between systems feels more natural and less cumbersome with FullPorts.

A small example: suppose we need to represent a device for which we know it will have a connector for all electrical leads, but without the details.

Somewhat later in the design, it is decided that two pins will be used for electrical power and four other pins will be used for a CAN bus.

How would you typically model that using proxy ports?

I know you could, but I'm mainly interested to see how you build this "incremental knowledge" into the model and how much manual labor it involves in the ProxyPort case wrt the FullPort case.

Thanks for your reaction,

Johan

[geoff]

Johan,

Have you examined the work of the OMG Systems Engineering Concept Model (SECM) Working Group on their interface_concepts_modeling_core_team wiki?

http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:interface_concepts_modeling_core_team

I'd like to suggest there might be some materials on the wiki's pages and presentations that may provide you some interface modeling insights.

Best Regards,
Geoff

[Stephan Roth]

Hello Johan,

I am not really sure if I understand your case respectively problem correctly.

You're talking about a system design model that has to be developed incrementally, and with each increment the model has to be enriched with more details, right? But that's nothing special, because incremental design is the way it should go in every complex systems engineering project.

I just tried to comprehend your example and model it accordingly. "Increment 1" might be the low-detailed first design you're talking about. "Increment 2" depicts the next development stage, where the simple electrical interface from "Increment 1" has been almost refined using the concept of nested ports. As you can see it is also possible using SysML Proxy Ports.

Hope that helps!

Best regards,

Stephan Roth

Trainer, Consultant, and Coach

oose Innovative Informatik eG

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To post to this group, send email to sysml...@googlegroups.com.
Visit this group at https://groups.google.com/group/sysmlforum.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/d48393d7-59b0-4e95-915b-8d0e8aa6e111%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 

Stephan Roth

[Johan Van Noten]

Hi Geoff,

Thanks for this reference, it seems my question is (more or less literally) included in one of the documents on that site:

http://www.omgwiki.org/OMGSysML/lib/exe/fetch.php?media=sysml-roadmap:interface_needs_r7.docx (section 3.6.c)

They recognize it to be a problem with the current SysML and they are looking for improvements.

@Stephan: thanks for your elaborated answer. As indicated in my previous post, I know that it is possible with Proxy ports, my main concern being the expressiveness/verboseness/maintainability.

Your solution certainly has the advantages of inner/outer port clarity, which is lacking in the FullPort approach (therefore it solves the initially posted question), and of interface/realization cleanness.

On the other hand it is somewhat more verbose: the Block1/2's ports are to be duplicated by ECU ports, additional connectors are required, InterfaceBlocks need to be explicitly defined, when refining the j1-1 connector specification (e.g. with hardware layout), an additional generalization hierarchy with redefinition needs to be build for the interfaces as well as for the affected Blocks. It also lacks the (far from perfect) physical connotation of being "on the border" of its owning Block.

So, I guess with the current state of SysML, it remains a bit of a balance.

Thanks for your feedback,

Johan