Creating a shared library of components with attributes

Hello, I’m part of a project that is in the early stages of product development and we’re rapidly reviewing lots of different product concepts. I’d like to create a PAB in Capella for each concept in order to give a an initial estimate/overview of what the components within such a concept might be, and provide a cost estimate.

I’d like to have a reusable library of parts with costs attached to these, and generate a few physical architectures using multiple instances of these parts (e.g. I might have a part which represents a high power AC motor, and I might need to use 3 of these in a single concept’s PAB). Then I’d like to calculate the cost for all the components in a given PAB.

So far, I haven’t found a good way to do this. I’ve considered:

  • Using REC/RPLs. Initially this seems like a good option, but it looks like you have to manually update every RPL if the REC changes. I want people to be able to update the cost for a part in the library and have all instances of that part update to match the new cost, without more manual work.

  • Some way to assign a class to a structure? (i.e. use the data modelling to add the cost to a class, assign this to each structure and change the cost value in the class). Only it doesn’t seem I can link classes to structures in Capella?

  • Use the Basic Price Viewpoint add-on and assign a single cost object to multiple structures? This could work and I think is my best option so far, but I’m not keen on how I’d have to link this object up to every instance of a part. Because we’re moving so quickly, I’d like a methodology that minimises the opportunity for human error.

Are there any better ways of achieving this in Capella? (I’m happy to write scripts in Python4Capella, but wanted to check what the best methodology was first before committing to this.)

I’m used to using SysML to model things, and previously to solve this problem I would:

  • create a set of blocks representing the types of structures in the model and assign these a tag representing cost.
  • create product/context blocks representing the different concepts and assign the structure blocks to these as parts.
  • write a script that goes through all the parts owned by a block, and sums their inherited cost tags.

Many thanks!

Indeed the REC/RPLs seems a good option. You should not have to manually update the RPLS. You can select multiple RPLs (that you may have set in a separate Catalog) and right click “REC/RPL → Update selected RPL from its REC”.

Hi Stephane, many thanks for the suggestion. Keeping all the RPLs in a package like you have shown may help.

I’ve had a play with this, but there are still quite a few manual steps involved to update a cost value across the RPLs. It seems I have to:

  • Update the cost in the component that defines the REC;
  • Update the REC - click through one menu;
  • Select all the RPLs in the package (is there a shortcut for this?);
  • Select to update all the RPLs;
  • Click ok and apply for each RPL.

So if I had ten RPLs of a component and I change the cost value linked to the REC, this means I would have to click through 21 menus to update every RPL. I was hoping there is something less manual than this?

Is there a way to get the RPLs to update automatically when the REC updates? Or some way to skip all the popup menus that appear when updating?

Thanks again.

Hi Jack,

The Semantic Browser can be useful to select the relevant REC.
You can browse (F9) until having the REC selected. From there, the RPLs will be listed on the left in the referencing elements. All that remains is to select those to be updated

That said, I agree that the interface could be improved. In particular, when updating an RPL it could be suggested to include others RPLs. And probably other aspects of the REC/RPL GUI.
So far, we haven’t had the budget to fund this work. However, if you (or anyone else interested here) is keen to sponsor this, feel free to contact me.

BR

1 Like

When creating your RPLs, have you looked at checking the option “Enforce RPL Compliance on the fly”?
I am not sure how functional this is, but I believe this is worth a try.
If you have not check this option, you can still go to each RPL and check it in the property view.
You may also want to have a look at the documentation in the section Capella Guide > User Manual > Replicable Elements > Validation of RPL

Thanks both. It seems there are a few options for finding and selecting the relevant RPLs, but if I have quite a few of them then this still takes a long time to manually update them all.

I’ve had a go at creating RPLs with this ‘enforce RPL compliance on the fly’ both enabled and disabled, but it makes no change to the process when updating the RPLs. Checking the help, it says: “To enable live compliancy validation for this RPL select “Enforce RPL Compliance on the fly”.” I’m guessing this means that it toggles whether any validation rules you define are checked when the RPL is updated or not?

The validation rules look like they can prevent certain types of undesirable modification to the RPLs, but it doesn’t affect how they are updated from the REC?

Perhaps an alternate strategy: I’ve noticed that when viewing the project browser with a different set of filters selected (such as in the Python or Java views), I can see both ‘Physical System’ and ‘Physical System : Physical System’. Is one a class and one an object like in UML? If so, is there a way to instantiate multiple objects from ‘Physical System : Physical System’ so that any changes to properties of the class are rolled through to the objects with immediate effect?

Thanks.

If you use PVMT to store the cost value, it can be updated without RECs/RPLs.

Create a library model. Include the cost as a property value within it.
Reference this library model in the required models.

Attach the property value to the required components.

Various ways of working in a single model using PVMT also.

Josh

Hi @JoshWedgwood,

Interesting approach using PV and the PVMT add-on to update ALL the cost parameter.
My understanding to update all PV defined by PVMT is by updating the default value in the PVMT configuration, agree? Is there any other options to update all PV defined by PVMT?

I believe @JackHutton needs to use REC/RPL to create several replicas of a system based on a definition of a model element.

Nevertheless, the question raised by JackHutton still remains, independently of a single model element property (e.g, cost), how to propagate an updated REC to ALL RPL?
At the moment the only option is to select any and all the RPL and updated them.

I believe an accelerator could be developed to provide the above feature, if there is a community interest. The need may be more evident when the number of RPL against the same REC grows in number.

Thanks,
Hélder Castro

Thanks Josh, I’d forgotten about libraries!

I gave this a try and sure enough when you update and save the library, it will close itself in the referencing project. When you open it again, the cost is updated to the new value.

This is very close to what I’m after then - the only problem is that you can’t have duplicates of this element in a single model. I need a few of instances of this library part per PAB (e.g. we have 3 of this type of hall effect sensor).

If there was some way to create new elements that point to library elements for their definition, or reference a library twice in a single project, then this would meet my needs. I’m doubtful this would be easy to implement though since the model and library elements share the same Id.

Ideally, what I want to be able to do is change a single cost value in a defining element and have this value be instantly updated for all copies of an element, i.e. a class-object relationship. I can achieve this in my SysML tool by using blocks and parts. By assigning the block a tagged value called cost and changing it, any parts that are instances of this block immediately have their cost tags updated without any further action needed from the user. The part essentially just points to the block for its inherited tags.

Here’s a generic example - if you change the cost tag of ‘AC Mains Motor’ or ‘Hall Effect Sensor’ while you have the IBD open, you can see these properties instantly update to match: