But I bet this is the version associated to Capella 5.1 I believe.
Same for .afm, et .capella.
I was wondering if there was any way to get associate a version to our current model? I saw we had a “last modified” in “ressources” (right click on the project). It can be deceiving because any mistake/ missclick + a quick ctrl+s will lead to a change of date. In any case, the info must be captured.
Apart from creating a property Value group somewhere inside one of the 4-5 levels of analysis, is there some feature realizing this particular need?
Hi,
Without connection to a PLM tool (I haven’t experienced it yet), my understanding is:
The model keeps being a kind of permanent draft: each save is a new subversion. To capture real versions, I would suggest to copy this state of today in a specific repository and do not modify again from there. It would be even better to export as HTML file, in which you save big part of the data, and freeze it almost as html is not easily modified. A doc issued from M2Doc would be a reference as well.
Then this version can be linked to some expected product version (following your change process): the main part then is the SA layer. LA to EA are to prepare subsystem SA. OA is about preparing the proper SA when you don’t get sufficient incoming specifications.
Note: Configuration Items and Physical Component Nodes are driven by defined product versions according to comitted functionalities by the design set, but the aim there is to prepare an achievable requirement set for subsystem, used as it is, or new variant, or white page new.
Yes that’s what I do, eventhough this does not work well with Python4Capella I saw, I will investigate this further later.
What do you mean? Export the diagrams as HTML or is it really exporting the model files as HTML? How does that work?
You mean, naming the M2DOC generated word (or inserting inside it) some reference to the model who’s name would be modified according to the ref somehow?
Hi,
You may add extensions to Capella, some are very important for configurations and to connect to product:
XHMTL: you may add it as dropin, this enables creating an html site that you can navigate as in internet. Have a look in extension part of downloads.
M2Doc is another extension which is a document maker that convert a copy of the model in a text built in MS-Word. This runs with some AQL queries extract from model. This is easier to read for people not used to html naviagtion and mainly can be print.
EA is sometimes mentioned instead of EPBS I just used it.
A very important extension is the transition to sub-system: With this you can select a component (Logical; Physical or better a configuration item), then you build automatically a file where this component is the system, in System Analysis layer.
Thierry
You normally begin the system engineering journey since operational analysis or system analysis when you have already your system scope defined. Then you divide your system in components in logical architecture and physical architecture. In physical architecture you define normally nodes in relation to product you have already in catalog (using defined product data where you get function commitments). Then you finalize the component perimeters with EPBS to include physical links somewhere, and have the proper relation to products. The configuration items you define there are in relation to expected product of these components. The transition to subsystem enables you to prepare a SA layer of one of your CI in a new projet initiation. If your supplier understands Capella, you may just deliver include in requirement book, if not you use XHTML export or M2Doc.
This new file should be used to generate versions that follow at least the expected product versionning for this component.