Correct flow breakdown in PAB?

I have recently started using Capella to model some of our existing systems. Primarily as an excersize to better understand the method and the tool.
However, I am quickly learning that the models will be valuable for us for a multitude of reasons.
I have been leaning on the book “Systems Architecture Modeling with the Arcadia Method - A Practical Guide to Capella”,
As the book usecase describe a top down, while i am doing bottoms up, i have a few questions related to best practices and modelling choices.
I have two computers running software communicating over ethernet via switches and a router.
Software A, sends an API request to Software B, Software B, then sends/updates a Datastream back to Software A
I have desire to show Software A communication with Software B, without showing the switches and Router (Flow 1)
I have desire to show Software A communication with Software B, including the switches(VLANs) and the Router (Flow 2)
I currently have the functional exchanges from the software to the switches and soforth, not between the softwares. This means my FC’s and dataflows is showing “all the hops” (Flow 2).
I have not figured out how best to show Flow 1.
How do i achieve both visualizations? Can i do both in the physical level at all?, or must i do the logical flow in the Logical Level? (note that i have avoided bringing this up to the Logical level at this time, as the logical level wouldn’t have visibility on the specifics of the API’s etc)
Can i hide parts of the chain, while showing there is connection?
Should i add Functional Exchanges between the softwares directly? (i’ve done this in the example below)
Should i add Component Exchange between Computer A and B (or add subcomponent for Software A/B, then add component exchange between them)
Should i consider the VLANs, Switches and routers purely physical entities and use Physical path for flow 1, while using Functional Chain for flow 2?
Any other mechanic i can lean on? (categories, and hiding one category perhaps?)
I’ve added a simplified example below
Flow 1:
Flow 2:
best regards

Hi Espen,
I have been using the Physical Paths to do what you describe, attached a picture showing it.
Explanation: focus on the functional exchanges between the behavior components. The physical links should make these functional exchanges possible, but there is no need to create behavior components, functions and component exchanges to all involved nodes. Physical Paths can cover a path over multiple physical links. The Capella validation rules can be used to make sure that all your component exchanges have been allocated (and that they are possible in your architecture).
Hope this helps.

Yes i see that adding too many functional exchanges will quickly become very deep. I have a notion right now, that functional exchanges should then only be between components that are “aware” of eachother.
I will make a few tests, as a I need to also represent VLAN’s and Trunks. Not 100% sure what is best way to highlight this. Thinking i could use one of the following:

  • Physical components for VLANS/Trunks,
  • Or the name of the connection (though i would prefer to use the Cable tag name for this)
  • Or, name the physical ports VLAN/Trunk (though i would prefer to have the port identifier for this (Ge 0/0/1)
  • Or, Use categories (though i would prefer to use categories for Fiber Multimode/Singlemode/Cat 6 etc)
  • Use “note-it, labels”
    Other suggestions?
    I have other places where i struggle in a similar fashion, and related to the physical/logical exchange:
  • I have software that communicate over serial port (Software C) with another Software (E)
  • I use other software to setup virtual serial ports (Software D). This software also sets up TCP Server/Client
  • The software C, is then not aware of Software D, only of the serial port it configures.
  • How then can i model the communication between the end softwares (C and E), while also documenting and modelling the configuration of the Virtual Serial port (IP and ports of the machines on each side)?
    Thanks again!
Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.