Hello,
I work on different models to represent the different sub-systems (lvl2) of my system of interest (lvl1).
Today, I maintain more than 5 models representing each a subsystem. I ensure and maintain the consistency of the interface between the sub-systems thanks to a high level model of the system (lvl1) and thanks to the add-on system to subsystem transition (vertical translation SA). Concretely, I transition the PA of my lvl1 model (through physical component that represent a subsystem) to SA of my lvl2 models.
However, I would like to create a physical view of the whole system architecture (especially showing data/elec interface). Today, I can create the physical view of each sub-systems models (lvl2), typically on a PAB diagram. But the external actors are not detailed in each sub-system model, so it is not appropriate to have the whole synoptic.
In addition, the idea would be to make sequences where all the components of the system of interest appears and this is not possible today with our modeling architecture.
I had the idea to make transition to a new model from all the physical layers of my sub-models with the add-on system to subsystem transition (scoped horizontal extraction). This should work and could be maintain with the Sid functionning.
However, I will be forced to redo “by hand” the interaction between components of different sub-systems which is not optimal as I have a lot of interactions between components of differents sub-system (creation of FE, allocation to CE, allocation to PL). Thus, it could be a waste of time and could generate a discrepency between this model used only to have a transversal view of the architecture and the sub-system models.
Does someone have any advice for this use case ? Our faced a similar problem ?
Thank you !
Edgar
Hi Edgar,
This is an interesting topic, you may find a related topic under Reconstruct Product Breakdown Structure
Thanks,
Hélder Castro
Hi Edgar
Then I have a question how do you link your models or models items to your PLM?
I can give you my idea:
The model with a SA layer complete shall link to expected product. Until this layer is modified, a stopped version is kept in safe.
Then Architecture layers are the beginning expectations for designed product answering to this expected product. This is versioned when you change your expectation, for this you need to duplicate your model before beginning LA. Then you have completed your model until the transition to subsystem. The subsystem model includes SA layer only and links again to subsystem expected product. Then again you duplicate before starting the subsystem designed product and populate LA and PA layers.
For me, as soon as your product is Hard Ware, it’s better to use the EPBS level to make sure no part playing a physical link is missing in the subcontract transferred to subsystem.
Beginning PA layer, for HW, PAB shall be linked to Digital Mock-Up to include proximity issues and additional physical links coming from them, constraint exchanges induced (Thermal exchange, vibrations for mechanics, for electronics you get as well wiring absence that induces gateway needs) unchosen emissions, exposures… For SW the PAB has to be linked to SW architecture: Pgm size, RAM needed, OS in lower layers; CPU needed, stock memory needed… Physical links exchange capacity as well.
So you get
-1 model SA connected to your expected product lev0 that you are answering to
-several models LA+ connected to your different proposal versions (variants may be include in same model if designed to run together) You version the LA+ model to change your proposal (which affects requirements to subsystems) since this model was shared to stake holder including supplier (internal or external to your organization)
From each version of this LA+ model, you have a set of subsystem SA which have change request coming from your new version of LA+ model of the product 0.
Then your supplier (may be yourself again) starts designing subsystem by LA layer in subsystem model, may decided changes in the proposal at this level. Until the changes do not impact the expected product lev1, it does not impact the designed product lev0: your LA+ model (which may include PA and EPBS layers). You may even have a version level to keep your logical strategy safe from your implementation hypothesis. To keep a version, I duplicate my model and export as html in a different folder than workspace. If you have a connector to your PLM tool, then these stopped copies are the data to be upload as submitted versions, going to release.
As summary, if the return link from lower subsystem to system is not “automatic” it’s basically because we are mainly on expected product side were we breakdown. On the side designed product, at release step, we consolidate Bills and Assemblies. Since physical architecture, we need designed product answer to make sure our expected product can be real, but we release first expected product including SA model, before releasing answering designed product, and then manufactured product
Thierry Poupon
Hello Hélder,
Thank you for this related topic. Indeed, my need is to reconnect the models to have a vision of the complete architecture. The only difference is that I’d like to have a model just for the physical architecture of my whole system, and thus see visually through Capella all the components of the system in Capella and their interactions (even between components from different subsystems).
But yes, a first step can be to recreate this architecture through model exports so thank you!
Edgar Sevestre
Thanks for your detailed answer Mr. Poupon.
Regarding your question, today we do not directly link our model elements to our PLM, this will probably be a next step but for the moment we consider the model as a tool for engineering and not a formal reference linked to the PLM.
To understand your methodology, you create N models for N subsystems, where the SA layer is a recopy of the SA layer of the system model, and where the LA and PA layers represent the architecture of the designed product, is that right ?
Otherwise I think I understand your methodology for breaking down the modeling levels, getting the right stakeholders involved at each level…
But since you breakdown with different models, regarding my question : how do you build a view of the trenasverse physical architecture across lvl1 for example knowing that the information is distributed in your N models representing your N sub-systems?
Thank you,
Edgar Sevestre
Hi Edgar,
I would like to ask you one question: Why have you used system to sub-system transition?
1 - Is it to tackle complexity by splitting in different models?
2 - Is it to give it away to different development teams or contractors?
If you plan to have one scenario diagram with all the physical nodes involved, I believe:
- It can be a big diagram, depending your product or service complexity, hence, not easy to follow.
- If the need is to allocate responsibilities, I suggest you to use PVMT in the PBS diagram and identify for each model element who is responsible for it. With PVMT you can also use colours to better identify each of them. Then you can organise your model by creating packages for each team.
I think it all comes to your/project needs and maybe you should start by answering the question above.
I hope that helps,
Hélder Castro
1 Like
First when the main system has a complete picture at SA layer, in a version with which can start, I stop the version and “upload” to expected product for this main system. This is the reference of the project content.
When the model is ready to send subsystem specification, it is released including a subsystem model with a SA layer (and a DMU with allocated volume, mass budget, or spec for CPU and memory budget…)
In fact I never consolidate: consolidation is done in technical models for physical items. Solving incident is by increasing impact creates:
-Manufacturing change request
-Design (Engineering) change request
-System change request: the concerned system has impact in its interfaces, capabilities in a manner that a change is required to supersystem. Then the supplier part has to request to customer. Then a new breakdown process runs again. From function (system) side, we should breakdown. Consolidation comes from solutions, and designed parts. Sometimes the consolidation does not meet expectations, and we need may be to change the breakdown: then we adapt the breakdown to converge to what is possible, and compare again to physical design.
At very early stage, may be some short cuts can be taken in the way the “solution” is designed, but the system engineering is always in descending part of the cycle. the climbing one is when we have a technical solution, so we can prepare samples (technical models or prototypes or pre-production) we can use in verifications (inspections/analysis/démo/tests). Test which will assess the pass or fail of requirements coming from the descending phase.
If for some reason you have to change interfaces between subsystems, it may be requested by one of them, but as system owner you have to agree or not, and then request application to all concerned subsystems.
1 Like
Helder,
We actually use system to subsystem transition mainly to be able to provide the model to different development teams so that they can make modification into it and to have one model owner who integrate the different sub-models.
Yes, I agree, one way could be to split the scenario diagram at different level so that development team create scenario diagram in their systemic perimeter answering to an upper scenario diagram.
Thank you for your advices !
Edgar
1 Like
Very clear, thank you for all these details, seems to be a clear process !
Edgar