Hi Stacy,
Several aspects can be considered to answer your questions :
1° Meaning of ‘Deployment’
From the Arcadia language point of view, there are only two notions related to “components inside other components”:
- each behavioral component can be ‘composed’ of other behavioral components that contribute to its behavior;
- each hosting component can be ‘composed’ of other hosting components that contribute to its assembly;
- behavioral components can be ‘hosted’ by hosting components.
‘Composition’ is to be considered with a weak semantics here; it just means that to use a component, you should consider it along with its composing “sub-components” as a whole. No other stronger semantics consideration is to be considered (such as UML composition vs aggregation, or the notion of parts, etc.). But this composition will also drive the PBS assembly tree as well.
In Capella, for compatibility reasons mainly, things are a bit more complicated. If you want to be aligned with Arcadia, I would recommend that : - behavioral components (BC) are related with each others by breakdown relations only (as seen in breakdown diagrams, and depicted in architecture diagrams as sub-components having square-angles rectangles)
- implementation components (nodes) are related with each others by breakdown relations only (same as for BC)
- BC are
deployed on Nodes only (no relation between BC and nodes in breakdown diagrams; and BC deployment on node being depicted in architecture diagrams as deployed BC having round-angles rectangles).
2° hosting of behavioral ports by physical ports
One of the major recommendations in Component-based Design (CBD) and in Arcadia is encapsulation : in order to use a (behavioral) component, you should as much as possible only need to know and use its external interfaces (and behavioral ports in Arcadia). If this “interface port” is in fact managed by a sub-component, then delegation should be used.
This is only a recommendation in Arcadia (some limited cases have been identified that may require direct exchanges between sub-components), but it is enforced by a creation rule in Capella (which could be subject to discussion).
So if you want to describe you embedded Linux as a behavioral component, then in Capella you have to create a Linux port and delegate the GPSD service port to this one, as you suggest.
3° Behavioral or hosting component ?
However, you might consider another option : what about creating the embedded Linux as a hosting component (node component in Capella) ? In your engineering scope, I suppose that you will not modify Linux “component”, and probably not allocate directly functions to it ? This looks more like a resource component hosting your software, rather than a true behavioral one.
If so, you could define Linux as a hosting component, having physical ports linked to embedded computer hardware physical ports by means of driver-supported connections (physical links); then these ports would host your GPSD service component ports (port allocation link in Capella).
Hope this helps.
Jean-Luc