How to use Capella to evaluate alternatives

Hello all,

I’m trying to use Capella for the development of a system comprising software, hardware, optical stages and mechanics. The system will have a couple of iterations, because we try to design it by first using high end components and gradually researching how low we can go in specifications in order to make our design economically sound. This is a research project, with lots of unknowns, so the first setup will probably be big, bulky and expensive and we hope the end result will be lean and mean.

I want to use Capella / Arcadia to have a common understanding between a lot of designers and stakeholders on who’s making what for what purpose. The capabilities and systems architecture are fine for me, but when going down to the logical architecture I don’t see how I could make several “implementations” and compare them. For instance, I’d like to show the impact of migrating from a PC-based architecture to embedded or PLC usage. Or show how choosing a low latency bus will impact system design. Or show how migrating functionality from one subsystem to another impacts the design.

Maybe this could be done using pure::variants, but that seems like overkill, or even inappropriate usage of PLE functionality.

So my questions are:

  • How do you use Capella for architectural reasoning? Do you make many models? Or do you unsynchronize after derivating a logical architecture from a system architecture? Or do your use git branches? Alls options seem like giving a lot of overhead…
  • (How) do you use Capella for documenting the choices you’ve made? I’m used to using Architecture Decision Records (ADRs), I’d like to show alternatives we did not choose, and why we didn’t choose them. In some cases, it’s good to have a consistent model to show influences of choices in multiple views…

Little bump for my own topic. I’ll elaborate on what I’m doing now to make the problem less abstract.

I know we want to have more capabilities in the future, but even though we use expensive equipment to explore our solution space, the first prototype / demonstrator will only have limited functionalites (and therefore less capabilities than what we end up with). I’d like to communicate a “roadmap” of solutions that we can go through. For example what logical architecture we could choose now that will probably stay more stable than an architecture that’s easiest to implement now. I can’t imagine I’m the first to want to do this, I’m very curious how you do this in Capella.

I don’t need a view that shows the differences or something like that, I’m just wondering whether you make several models to describe potential differences (which kind of seems to become a pain to maintain), or do you use variants, or… ?


Managing variations has come up a few times in the forum. From a quick search of previous topics…

In the first instance I would look at this: Multiple Physical Architectures

With respect to variant modelling and a 150% model (similar but not exactly what you are after) I suggest you look at this topic: variant management

I think you have an extra challenging situation as you are looking to model not only current alternatives (LA/PA) for a fixed set of black-box needs analysis (SA) but also an evolving needs analysis (SA). You will have to think carefully about what you want to model now vs in the future.

For modelling your current set of alternatives…

Within a single model this will always be clunky if you start creating multiple versions of functions,behaviors, components. Possible but not recommended. Guidance available in the various books suggests:

  • Using multiple models and a version control management system (e.g. GIT)
  • Using RECs/RPL to reduce the modelling overhead. This way you can model your various architectural options once then you only have to do the integration modelling/thinking. You dont have to model your embedded PLC each time, just model it once then place it in the model you want to explore the use of.

With respect to documenting choices, the decision of which architecture to go with will not only be based upon the system architecture model but also various analysis and trade studies which all go into the decision making mix. You can reference this back against a given Capella model version controlled in your ADR as well as your wider analysis.

Hope this helps.

1 Like

Hi Josh,

Thanks for your elaborate answer. I’m going to do it the way you suggested, using multiple models in the same git repository, and adding a library to that same repository to keep all REC/RPL synchronized and retrievable.
I still have “The arcadia method” book in backorder (or at least… it’s somewhere in our obfuscated purchasing system), would there be other recommended reading material for Arcadia/Capella that would adress things like this?

This may help: