Creating One To Many Physical Links between Physical Components in PA

Hi all, hopefully a simple question. At present I am only able to make point to point physical links between components in my PA. How do I represent a One:Many databus such as CAN or A429?

I’d link to be able to show that a physical link has multiple destinations. Ideally I don’t want to have multiple point to point connections with the same name, as this doesn’t represent the architecture; also I have tried creating multiple physical links connected to the single output physical port of the source component but this looks similarly wrong.

Really appreciate any help that could be provided.

Hi JFAvi8,

You’re addressing a very commonly asked question.

See Jean-Luc Voirin’s answer below extracted from Arcadia Q&A (Model building hints → How to engineer and model communication layers).

The way to model a system which includes communication layers (such as the 7 layers OSI model) is interesting, because it emphasizes the different scopes that different engineering teams have to deal with, and how they should articulate with each other.
Let us imagine a system in charge of supervising scattered installations on the Mars planet, environmental constraints requiring developing a new ruggedized, specific communication stack. Here, we consider the top level system engineering model.

  • The top level system engineering team should usually:
    • focus on the application-level processing and communication needs : collect status of installations, send them to a monitoring application, delivering appropriate human-system interfaces etc… A major goal is specifying this need to application software teams for example,
    • also specify the underlying communication infrastructure to the communication engineering team, by describing what kinds of communications should be supported, with which performance and QoS constraints (see below),
    • and integrate both, mainly focusing, at its high level, on operational, applicative scenarios and application level exchanges, the use of the communication means being implicit and hidden (provided that communication means had been validated separately before being integrated with application software).
  • From an application (software) component engineering point of view, the component never has two different kinds of interfaces that cohabit: if you consider the software code of the application component, for example, it only communicates with other application level components, by sending messages, events, requests or so. It has no explicit call to low level communication API for example.
    So what the software application team expects as a specification, only deals with
    • application level exchanges,
    • and possibly the kind of service to be used for each communication exchange (if not to be decided by software team).
      Therefore, putting both application- and protocol-related interfaces on the application components would have no meaning.
  • From the communication engineering team point of view, they have no need to get all the application level exchanges as an input, to define and build their communication stack; what they need is:
    • the different kinds of communication services, styles and paradigms that are necessary in order to implement the expected behavior,
    • expected quality of service for each service,
    • some kinds of ‘communication performance profiles’ that will define how the communication infrastructure will be solicited (how many services of each kind per second, size of transported data, real-time and scheduling constraints, and so on).

This requires enriching the description of each application level exchange (or exchange item) in top level system engineering model, with complementary properties (such as required communication service or paradigm), and then synthesizing them so as to specify expected communication services.

The means to define the performance profiles is trickier, and depends a lot from the level of detail in the system engineering model, and the details of the dynamic behavior description. It might have to come from another separated (non Arcadia?) model, more dedicated to performance issues.

Furthermore, system model, application software model and communication model have different lifecycles: adding or removing a new application exchange in the former will (and should) not affect the latter (the communication model).

Now, a question could be raised: is there any reason to include some description of communication subsystem in the top level system engineering model? The answer may be ‘yes’ if the communication infrastructure is likely to impact the system architecture definition: for example by adding dedicated communication components, or influencing performance analysis (communication layers might consume some resources in the system), and also to specify to the communication engineering team the network nodes that have to be fed with communication capabilities, and more…

In this case, both application level and communication level “sub-models” will coexist in the same top level system engineering model, but the communication sub-model would be less detailed: for example, you could define only communication components (because of their need for resources), communication services functions and functional exchanges (if needed for specification), but no protocol-related component exchange and interface. You should not try to link both sub-models explicitly, with exchanges, for example, because of the reasons above.

One way to express, in the top level system (application) engineering model, ‘the relation between “the required communication services in the application model” with “the provided communication services by the communication model”’, could be (among others) to

  • formalize these services as functions of the communication infrastructure,
  • name the ‘paradigm’ (or ‘communication service’) properties on application level exchanges accordingly,
  • and check, by means of model queries, that each application exchange is typed according to one existing service function name.
    Note: this situation also applies to other fields beyond communication stacks engineering, such as cyber engineering for example.

For more tips like this, take a look at the very rich Arcadia Q&A webpage or the recent webinar by Jean-Luc on this subject.


Hi Samuel,

Thanks for your detailed reply from the previous posts and the links.

At present I am focusing mostly on physical architecture connectivity whereby a single physical node in my physical breakdown has interfaces that have multiple target nodes in the real world.

Perhaps I have to model a physical component to represent a databus and have point to point connections to it to represent the many users of the bus.

Is it the case that a Physical link may only be point to point between two physical nodes?


To illustrate the situation which I believe is very common, I have created purely for demonstration purposes a Safety Critical Processing Unit (SCPU) that sends messages across a single CAN bus to three Distributed Control Units (DCUs). I have duplicated functional exchanges, allocated to individual component exchanges between the devices.

To replicate the CAN data bus I created three physical links between the SCPU and each of the DCUs, with the component exchanges allocated accordingly, that all originate from the same Physical Port on the SCPU and for clarity I’ve named them all the same CAN Bus #1.

Is this an acceptable way of doing it, and will it cause me semantic issues of having a single electrical databus represented as three separate physical links?


Hi Juliet,

To me, it seems perfectly fine.
Perhaps others on the forum will have a different opinion but, generally speaking, there is no single ‘right’ way to model.
Or rather, it’s the one that provides effective support for your engineering. And so, if it suits your team to represent things in this way or if it enables further analysis, that’s fine by me!